Re: git-rerere observations and feature suggestions

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