Re: rebasing merges

[Andreas Ericsson <ae@op5.se>]

Samuel Tardieu wrote:
> 
> 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