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

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

 



On Jun 15, 2012, at 8:52 AM, Junio C Hamano wrote:

> "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.

Thanks!  I'll repost the patch based on rerere.autoupdate for further discussion.

Dave

--
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]