Re: [RFC] Git rerere and non-conflicting changes during conflict resolution

From: Jeff King <peff@peff.net>
Date: Jul 25, 2017, 17:52 UTC
Message-ID: <20170725175202.ar4ykqoadbihwb2w@sigill.intra.peff.net>
In-Reply-To: <17c46229-3b64-34f1-30fa-d40b77e1c054@gmail.com>

On Tue, Jul 25, 2017 at 11:09:55AM -0400, Raman Gupta wrote:

Show 11 quoted lines

> I had an interesting situation today: resolving a merge conflict
> required modification in other files that were not themselves conflicting.
> 
> I just realized that rerere does not remember any changes to these
> additional files -- only changes to the conflicting files. This makes
> the end result of rerere obviously incorrect in this situation.
> 
> So my questions are:
> 
> 1) Is this a known limitation or is there a reason rerere works in
> this manner?

Yes, it's known. Rerere works by storing a mapping of conflicted hunks to their resolutions. If there's no conflicted hunk, I'm not sure how we'd decide what to feed into the mapping to see if there is some content to be replaced.

That said, I'm far from an expert on how rerere works. Junio might have ideas on how we could handle this better. But I do note that for repeated integration runs (like we do for topics in git.git, as they get merged to "pu", then "next", then "master"), he keeps non-conflict fixups in a separate commit which gets squashed into the merge automatically. See

  https://github.com/git/git/blob/todo/Reintegrate#L185-L191

> 1b) If it is a limitation/bug, what would be needed to fix it? With
> some guidance, I might be able to submit a patch...

As far as I know, something like the Reintegrate script above is the state of the art. IMHO it would be useful if something similar were integrated into rerere, but I'm not sure exactly how it would know when to trigger.

> 2) In the meantime, is there a way I can identify these cases, without
> which I cannot really trust rerere is doing the right thing?

I do think it would be useful if rerere could look at a merge result and say "OK, I've recorded these bits, but there are other lines that are not part of either parent and which are not part of a conflict". That gives you a warning that such lines need to be part of a fixup (rather than you being surprised when you redo the merge later and have to rework the fixup).

But I don't think even then you can ever trust rerere fully. Fundamentally you're applying some changes from one merge into another context. There may be new sites that also need fixing up, and the tool has no way to know. So you should treat a rerere-helped merge as any other merge: assume it's a good starting point but use other tools (like the compiler or automated tests) to confirm that the result is sensible.

-Peff