Re: git-rerere observations and feature suggestions

[Ingo Molnar <mingo@elte.hu>]

* Junio C Hamano <gitster@pobox.com> wrote:

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

in our workflow, we dont ever do any semantic things during the 
integration run. I.e. we dont put more complex merge changes into the 
integration merge commits.

Such integration effects do come up occasionally (especially when a 
topic changes some widely used infrastructure), and we handle them via 
separate merge branches. The current ones in -tip are 
tip/tracing/ftrace-mergefixups and tip/tracing/mmiotrace-mergefixups.

They are one or two orders of magnitude more rare than regular 
conflicts, and they show up immediately during testing. (or we 
anticipate them beforehand)

i.e. we'd like to have a 'dumb' phase of integration, as much cached and 
automated as possible. Things that need more thought need to go into 
separate branches anyway, for better reviewability - merge commits are 
rather hard to debug as they hide their true contents, so we try to keep 
them simple and contextual only.

	Ingo