Re: rebasing merges

From: Andreas Ericsson <ae@op5.se>
Date: Sep 23, 2008, 08:06 UTC
Message-ID: <48D8A371.4030909@op5.se>
In-Reply-To: <2008-09-23-09-30-47+trackit+sam@rfc1149.net>

Samuel Tardieu wrote:

Show 6 quoted lines

> 
> Btw, would it be a good idea to unconditionally enable "rerere"
> conflict resolution *recording*, and add an option to "rebase" and
> "merge" to use "rerere" even when it is not enabled in the
> configuration file? I can't think of any drawback.
>

I'm all for that. I actually thought (4 months ago) that that was how it worked.

It would be a backwards incompatible change though, as we currently fall back to "does rr-cache exist?" to determine if rerere is enabled in case it isn't explicitly so in the configuration. Perhaps print a warning if !rerere.enabled but $GIT_DIR/rr-cache exists. OTOH, that will create a lot of warnings since we'd have to create that rr-cache directory to record the resolutions.

To maintain backwards compatibility, we could ofcourse do like this;
* move rr-cache to rere ("recorded resolutions"; bikeshed color goes here)
* if rr-cache exists, implicitly enable rerere
* if rr-cache holds resolutions when setting up rerere, move them
  to rere
OR
* look for resolutions in both rr-cache and rere indefinitely.

It's not exactly performance critical, so swapping the pattern from O(n) (or whatever it is now) to O(2n) for replaying resolutions probably won't make that much of a difference.

-- 
Andreas Ericsson                   andreas.ericsson@op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231