status and commit uses different algorithms to find changes

[Alexander Belchenko]

John Arbash Meinel пишет:
>> 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.
> 
> 
> iter_changes gives the correct results when comparing 2 trees.
> 
> commit after a merge has to record information about 3 trees. base
> parent, merged parent, and current tree.
> 
> As I said before we *could* use iter_changes as it is right now in the
> case of a single parent (no merges).
> 
> "bzr status" after a merge only shows the changes versus the base
> parent, which is generally what you want anyway. But for *commit* you
> need to be aware of what was in the base parent, what was brought in
> from the merge parent, what is new between both sides.

I'm still don't understand why you need to compare against each parent.
bzr force user to use silver mainline in most of the cases. Why you
need track changes against merge parent?
Just to write down merge point in file graph? Why this cannot be obtained
as output from graph merge algorithm? Why you need to compare trees?
In the case of octopus merge you need to compare against 3 and more parents.

So why bzr don't run iter_changes N times to compare N trees and collect results?
It's slow?
IIUC, result of N comparing will be summed up to get resulting set of changes.

Anyway, to collect changes in the tree against parent iter_changes should be used,
because they're designed to get correct diff between working and revision tree.
Because working tree should be filtered out correctly before comparison.

And anyway I don't understand why commit uses os.lstat. It's wrong.
It's break not only with case-insensitive filesystem but with fake symlinks too.

As said: anything I did is sucks by commit.