Re: [PATCH] rebase -i -p: use rerere to resolve conflicts if enabled

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



"David D. Kilzer" <ddkilzer@xxxxxxxxxx> writes:

> From: "David D. Kilzer" <ddkilzer@xxxxxxxxxx>
>
> 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.
--
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


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]