On Tue, 26 Apr 2005, Linus Torvalds wrote:
I'll need to fix that up, because right now it does the wrong thing (which
it has always done): since we _remove_ all the merge entries, we'll first
warn about them, but then we'll show the original file going away if there
was one. Which is bogus.
Fixed. I think. My solution is clever, but untested.
What I do is that instead of _removing_ the unmerged entries (which we
can't do, or we'd later think that the file has gone away if we see that
same name in the tree we're comparing against), I make all unmerged
entries be in "stage 3".
Then, when we read in the tree to compare against into stage 1, we have a
few cases:
- stage 0 only: new file
- stage 0 and 1: modified file
- stage 1 only: deleted file
- stage 1 and 3: unmerged
- stage 3 only: unmerged
See any problems with this? (a mix of 0 and 3 cannot happen - a file is
either unmerged or it is ok, since inserting a stage 0 entry always
removes all unmerged entires).
Linus