Re: [PATCH] rebase -i: give rerere a chance

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

 



Johannes Schindelin <Johannes.Schindelin@xxxxxx> writes:

> Hi,
>
> On Wed, 28 Nov 2007, Junio C Hamano wrote:
>
>> Johannes Schindelin <Johannes.Schindelin@xxxxxx> writes:
>> 
>> > @@ -166,13 +167,13 @@ pick_one_preserving_merges () {
>> >  			msg="$(git cat-file commit $sha1 | sed -e '1,/^$/d')"
>> >  			# No point in merging the first parent, that's HEAD
>> >  			new_parents=${new_parents# $first_parent}
>> > -			# NEEDSWORK: give rerere a chance
>> >  			if ! GIT_AUTHOR_NAME="$GIT_AUTHOR_NAME" \
>> >  				GIT_AUTHOR_EMAIL="$GIT_AUTHOR_EMAIL" \
>> >  				GIT_AUTHOR_DATE="$GIT_AUTHOR_DATE" \
>> >  				output git merge $STRATEGY -m "$msg" \
>> >  					$new_parents
>> >  			then
>> > +				git rerere
>> 
>> This comment is not about this rerere change, but output is a shell
>> function and I vaguely recall we had a discussion on "VAR=VAL cmd" form
>> of single-shot export not working for them as expected...
>
> Hmm.  What do you propose?  In the long run, I _want_ to have rebase as a 
> builtin, which would solve this problem, probably.  But in the short run?

Well, something like

if ! ( GIT_xxx=A; export GIT_xxx; output git merge ... )

should likely work.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum
-
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]

  Powered by Linux