On 25/07/17 01:52 PM, Jeff King wrote: > On Tue, Jul 25, 2017 at 11:09:55AM -0400, Raman Gupta wrote: > >> 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 Seems relatively simple to me, at least conceptually. 1) Store the state of the index after the merge. 2) After conflict resolution is complete (i.e. user executes "git commit"), diff index @ step 1 with commit. 3) Assume that all changes in that diff are related to conflict resolution (as they should be), and save that diff to the rerere cache. I could be missing something fundamental here though... >> 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. I've seen the Reintegrate script before. It is very specific to the git.git workflow. I think it makes sense to expose this particular capability in git proper, given that rerere itself is exposed. Plus that could actually simplify the Reintegrate script a bit. >> 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). Agreed. > 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. While I agree that every case cannot be handled, and this type of validation is still necessary, I believe git should cover the cases which it is proper and possible to cover. > -Peff > Regards, Raman
