Re: git-rerere observations and feature suggestions

From: Junio C Hamano <gitster@pobox.com>
Date: Jun 16, 2008, 19:10 UTC
Message-ID: <7vabhlb3ho.fsf@gitster.siamese.dyndns.org>
In-Reply-To: <7vej6xb4lr.fsf@gitster.siamese.dyndns.org>

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

Show 11 quoted lines

> 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.