Re: [PATCH] rebase -r: always reword merge -c

[Phillip Wood <phillip.wood123@gmail.com>]

Hi Dscho

On 29/04/2019 17:14, Johannes Schindelin wrote:
> Hi Phillip,
> 
> On Fri, 26 Apr 2019, Phillip Wood wrote:
> 
>> From: Phillip Wood <phillip.wood@dunelm.org.uk>
>>
>> If a merge can be fast-forwarded then make sure that we still edit the
>> commit message if the user specifies -c. The implementation follows the
>> same pattern that is used for ordinary rewords that are fast-forwarded.
>>
>> Signed-off-by: Phillip Wood <phillip.wood@dunelm.org.uk>
>> ---
> 
> OMG I was bitten twice by this very bug in the past week, and planned on
> looking into it next week. Thanks for beating me to it.
> 
> Two comments:
> 
>> diff --git a/sequencer.c b/sequencer.c
>> index 0db410d590..ff8565e7a8 100644
>> --- a/sequencer.c
>> +++ b/sequencer.c
>> @@ -3248,6 +3248,10 @@ static int do_merge(struct repository *r,
>>   		rollback_lock_file(&lock);
>>   		ret = fast_forward_to(r, &commit->object.oid,
>>   				      &head_commit->object.oid, 0, opts);
>> +		if (flags & TODO_EDIT_MERGE_MSG) {
>> +			run_commit_flags |= AMEND_MSG;
>> +			goto fast_forward_edit;
>> +		}
>>   		goto leave_merge;
>>   	}
>>
>> @@ -3351,6 +3355,7 @@ static int do_merge(struct repository *r,
>>   		 * value (a negative one would indicate that the `merge`
>>   		 * command needs to be rescheduled).
>>   		 */
>> +	fast_forward_edit:
> 
> It is *slightly* awkward that this is an `else` arm of an `if (ret)`, but
> I do not necessarily think that it would be better to move the label
> before the `if` than what you did; Your version comes out more readable,
> still.

I did wonder about adding braces but I'm not sure that makes it any 
clearer. I agree having the label before the `if (ret)` would be less 
clear as the reader has to then think what ret will be in that case to 
work out what will happen.

>>   		ret = !!run_git_commit(r, git_path_merge_msg(r), opts,
>>   				       run_commit_flags);
>>
>> diff --git a/t/t3430-rebase-merges.sh b/t/t3430-rebase-merges.sh
>> index 4c69255ee6..3d484a3c72 100755
>> --- a/t/t3430-rebase-merges.sh
>> +++ b/t/t3430-rebase-merges.sh
>> @@ -164,6 +164,16 @@ test_expect_success 'failed `merge <branch>` does not crash' '
>>   	grep "^Merge branch ${SQ}G${SQ}$" .git/rebase-merge/message
>>   '
>>
>> +test_expect_success 'fast-forward merge -c still rewords' '
>> +	git checkout -b fast-forward-merge-c H &&
>> +	set_fake_editor &&
> 
> set_fake_editor affects global state AFAIR (setting and exporting
> `EDITOR`), therefore this would need to be run in a subshell, i.e.
> enclosed in parentheses.

The other test files are not very consistent about that. I'll re-roll. 
Note that I do not export any FAKE_* variables, so later tests should 
not be affected even if the fake editor runs.

Best Wishes

Phillip
>> +	FAKE_COMMIT_MESSAGE=edited GIT_SEQUENCE_EDITOR="echo merge -c H G >" \
>> +		git rebase -ir @^ &&
>> +	echo edited >expected &&
>> +	git log --pretty=format:%B -1 >actual &&
>> +	test_cmp expected actual
>> +'
>> +
> 
> The rest looks good, thank you!
> Dscho
> 
>>   test_expect_success 'with a branch tip that was cherry-picked already' '
>>   	git checkout -b already-upstream master &&
>>   	base="$(git rev-parse --verify HEAD)" &&
>> --
>> 2.21.0
>>
>>