Elijah Newren <new...@gmail.com> writes:
> Yes, precisely. Checking the *current* index is not reliable in the
> presence of renames.
> Trying to use the current index as a proxy for what was in the index
> before the merge started is a problem. But we had a copy of the index
> before the merge started; we just discarded it at the end of
> unpack_trees(). We could keep it around instead. That would also
> have the benefits of making the was_dirty() checks more accurate too,
> as using the mtime's in the current index as a proxy for what was in
> the original index has the potential for the same kinds of problems.
Yeah, I agree that you are going in the right direction with the
> It's certainly tempting as an interim solution. I have an alternative
> interim solution that I think explains well why the code here had been
> fragile, and how to just implement what we want to know rather than
> making approximations to it, which I just posted at . But I can
> see the draw of just gutting the code and replacing with simple brute
Thanks; I'd love to reserve a block of time to think this through
myself, but I am a bit occupied otherwise this weekend, so I'll try
to catch up after that.