Junio C Hamano <gitster@pobox.com> writes:

quoted text
> Ingo Molnar <mingo@elte.hu> writes:
> ...
>>  - Automation: would be nice to have a git-rerere modus operandi where
>>    it would auto-commit things if and only if all conflicting files were 
>>    resolved.
>
> I am not sure how safe this is.  rerere as originally designed does not
> even update the index with merge results so that the application of
> earlier resolution can be manually inspected, and this is exactly because
> I consider a blind textual reapplication of previous resolution always
> iffy, even though I invented the whole mechanism.

By the way, this safety is not a theoretical issue but has been a real
one.  I had two topics that changed the calling convention of the same
function in different ways, and when they were merged to 'pu', the
declaration, definition, and call sites existed on both of these branches
were handled beautifully by rerere.

Recording autoresolution would have been a wrong thing to do.  One of the
branches added a new call site to a file that was not among the ones that
conflicted in the merge between the two branches.  That call site, that
uses the calling convention of one branch, needed to be adjusted to
accomodate the change of calling convention from the other branch (from
textual merge's point of view, this has to be an evil merge).  I had to
make and keep a mental note about that new call site until both topics
graduated to 'master' (similar to your need to remember a particular merge
is resolved to removal right now).

To safely automate reapplication of such a merge, rerere needs to become
much more clever.

The conflicts rerere notices and records are strictly per blob.  A
conflicted merge to a blob is inspected and a "conflict signature", which
becomes the directory name under rr-cache, is computed.  We record the
conflicted blob as a whole as the preimage, and your hand resolution as a
whoe as the postimage.  Next time when you have a conflicted merge to a
blob, and the conflict has the exact same conflict signature, we run
three-way merge between the recorded preimage, postimage and the new
conflicted result.

If we want to handle new call sites added only on a single side, you
should be able to express something like "when a merge has a conflicted
blob with this conflict signature, look in the whole tree, even outside
the set of conflicted paths, and change this text to that".  This is too
much automation and I somehow think the potential for errors (both from
the tool and from the user) is too high.



--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html