Re: [PATCH] Test that the 'rebase -i' "reword" command always cherry-picks a commit.

From: Marc Branchaud <marcnarc@xiplink.com>
Date: Mar 23, 2010, 14:38 UTC
Message-ID: <4BA8D263.8040602@xiplink.com>
In-Reply-To: <7vd3yw84pd.fsf@alter.siamese.dyndns.org>

Junio C Hamano wrote:

Show 16 quoted lines

> Marc Branchaud <marcnarc@xiplink.com> writes:
> 
>> In particular, "reword" should cherry-pick a reworded commit even if the
>> commit's message is unchanged.
>>
>> This behaviour provides a way to deal with a situation that can arise when
>> a merge had to be reverted.  Added an addendum to revert-a-faulty-merge.txt
>> describing the situation and how to use "reword" to handle it.
>> ---
>>
>> Is this more acceptable than adding --no-ff to rebase--interactive?
>>
>> I wasn't sure how to integrate the new text into revert-a-faulty-merge.txt.
>> I went with an addendum, but I'm open to other approaches.
> 
> The addendum looked readable, but I am a bit puzzled.

Ya think _you're_ puzzled?  :)

Show 25 quoted lines

> "rebase -i --no-ff"
> already exists, and is probably a more natural way to do this than saying
> "reword" but not rewording anything, no?
> 
> I would actually say "rebase -f P" would be even easier and clearer,
> especially as...
> 
>> ...
>> +However, you could avoid these problems if you recreated the entire branch,
>> +including commit A:
>> +
>> + P---o---o---M---x---x---W---x
>> + |\         /
>> + | A---B---C   <-- old branch
>> + \
>> +  A'---B'---C' <-- entirely recreated branch
>> +
>> +Now you can merge A'-B'-C' into the mainline branch without worrying about
>> +first reverting W.
>> +
>> +But if you don't actually need to change commit A, then you need some way to
>> +recreate it as a new commit with the same changes in it.
> 
> ... this part seems to talk about working around the tendency of 'rebase -i'
> to fast-forward.

Yes.  Thanks for pointing this out, it's cleared up a lot for me.

I was confused about the purpose of "rebase -f". Jonathan Nieder even pointed me to it when I posted my original patch for "rebase -i --no-ff", but the description in the man page threw me:

	Force the rebase even if the current branch is a descendant of
	the commit you are rebasing onto. Normally the command will
	exit with the message "Current branch is up to date" in such a
	situation.

I didn't realize that this is exactly the situation that "rebase -i" normally deals with (-i basically implies -f), and that "rebase -f" would do exactly what I wanted "rebase -i --no-ff" to do.

But I think I see an approach that might make sense:

 - Teach "rebase -i" to recognize the -f parameter (instead of --no-ff).

 - Update rebase's man page to better explain -f.

 - Update revert-a-faulty-merge.txt to explain how to use "rebase [-i] -f".

I'll submit a new patch shortly.

M.