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@xxxxxx
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
