Elijah Newren <newren@xxxxxxxxx> 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 above. > 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 [2]. But I can > see the draw of just gutting the code and replacing with simple brute > force. 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.
