status and commit uses different algorithms to find changes

[Alexander Belchenko]

John Arbash Meinel пишет:
> Alexander Belchenko wrote:
>> Hi John,
> 
>> Once not so while ago we talked in IRC and I said that it's to sad that
>> commit don't use
>> working tree's iter_changes() method to collect changes for commit. As I
>> remember you
>> said that it's not true and in reality commit uses it.
> 
> I wouldn't have said that, as I know commit does *not* use
> iter_changes(). It can't, because of issues when there are more than one
> parent. We have to compare against both sides, *and* pay attention to
> last-modified revisions, while iter_changes() does not.

Stop. I should make frank confession that I don't understand this.
Perhaps I'm inevitably stupid.

You said that commit should compare against both sides, otherwise what?

You want to say that after merge both `bzr status` and `bzr diff` show to user
*wrong* info? IIUC they both are used iter_changes under the hood. Is it true?
So they are produced wrong output? Is it true?
So all this years I've used bzr diff to see merge result, and all this years bzr lies me?
Am I understand correctly?

I think something wrong here in either case. Because I don't understand how it possible
to see *right* output from status and diff after merge, while they're using iter_changes
and in the same time claim that iter_changes wrong for collecting changes for commit
pending merges.

I'm totally lost here.