Re: git-rerere observations and feature suggestions

From: Junio C Hamano <gitster@pobox.com>
Date: Jun 16, 2008, 20:50 UTC
Message-ID: <7vskvd9kai.fsf@gitster.siamese.dyndns.org>
In-Reply-To: <20080616190911.GA7047@elte.hu>

Ingo Molnar <mingo@elte.hu> writes:

Show 16 quoted lines

> * Junio C Hamano <gitster@pobox.com> wrote:
>
>> >  - 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.
> ...
> So i'd not mind if git-rerere was safe by default, but it would be nice 
> to have some knob to turn it into something fast and automatic. For us 
> it would be much _safer_, because right now most of our manual energy is 
> spent on checking something that could be automated.

Oh, "unsafe switch" that is off by default will not hurt anybody, and I do not mind it as a new feature. We are in agreement in that sense.

Perhaps the way forward would be (and this is independent of the issue of recording removal as a possible form of resolution):

 (1) Introduce a new configuration rerere.autoupdate that is off by
     default, but when it is on, paths cleanly resolved by rerere will
     also be updated in the index (if we have capability to record
     removal, this may remove such a path from the index as the result).

 (2) The callers of rerere that expects rerere to resolve needs to be
     changed to see if the resulting index after rerere is fully merged,
     and continue.  Currently the callers are "merge", "rebase" and "am",
     I think.  This step might be a bit more involved than you might
     think, as rerere currently happens in the codepath that knows the
     caller does _not_ go further than leaving the failed conflict to be
     sorted out by the user (rerere is designed as merely a way to help).

     Also you _might_ want a separate configuration rerere.autocommit to
     control this --- the user (but not you) might be willing to allow
     autoupdate but you may still want to eyeball the result.

Independent of the above, we have two potential new features:

 * Introduce "git rerere revert paths..."  that brings the index and
   working tree back to the conflicted state after a previous resolution
   is applied, because that resolution is incorrect.  The old resolution
   cached in rr-cache is also removed.

   This however will become much less useful if you allow autoresolution
   to be committed automatically, as the caller will move ahead without
   giving you a chance to say "oh, that one is bad -- do not proceed".

 * Somehow record the fact that the resolution for a particular conflict
   signature is to remove the resulting path.