Re: [PATCH] rebase -i -p: use rerere to resolve conflicts if enabled
- From
Junio C Hamano <gitster@pobox.com>
- Date
- Jun 15, 2012, 15:52 UTC
- Message-ID
- <7vwr38bmj5.fsf@alter.siamese.dyndns.org>
- In-Reply-To
- <1339769855-94161-1-git-send-email-ddkilzer@kilzer.net>
"David D. Kilzer" <ddkilzer@kilzer.net> writes:
Show 5 quoted lines
> From: "David D. Kilzer" <ddkilzer@kilzer.net> > > When performing an interactive rebase that preserves merges with > rerere enabled, the --rerere-autoupdate switch should be passed > to git-merge.
I do not understand the above reasoning.
"rerere" is enabled in "merge" used in this codepath already, so after it runs, you will see the result of automatically replaying a previous resolution without your patch.
The configuration rerere.enabled *never* meant that the user blindly trusts the result of replaying a previous resolution. If you were checking rerere.autoupdate configuration variable, the patch may have made some sense, but basing the decision on rerere.enabled (which by the way is not necessary to trigger the rerere machinery these days, as long as $GIT_DIR/rr-cache/ directory exists) sounds very wrong.