Re: [PATCH v5 1/5] rebase -i: add --ignore-whitespace flag

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

Hi Danh

On 29/06/2020 15:14, Đoàn Trần Công Danh wrote:
> Hi Phillip,
> 
> On 2020-06-26 15:43:00+0100, Phillip Wood <phillip.wood123@gmail.com> wrote:
>>>> +	if (options.type == REBASE_APPLY) {
>>>> +		if (ignore_whitespace)
>>>> +			argv_array_push (&options.git_am_opts,
>>>> +					 "--ignore-whitespace");
>>>> +	} else if (ignore_whitespace) {
>>>> +			string_list_append (&strategy_options,
>>>> +					    "ignore-space-change");
>>>> +	}
>>>> +
>>>
>>> Hm, I've just noticed this by now.
>>> Would it's better if we rewrite it as:
>>>
>>> 	if (ignore_whitespace) {
>>> 		if (options.type == REBASE_APPLY)
>>> 			argv_array_push(&options.git_am_opts,
>>> 					"--ignore-whitespace");
>>> 		else
>>> 			string_list_append(&strategy_options,
>>> 					   "ignore-space-change");
>>> 	}
>>>
>>> Ah, the incoming patches will add more conditions into the:
>>>
>>> 	if (options.type == REBASE_APPLY)
>>>
>>> I'm still not convinced, though.
>>
>> I wanted to keep the subsequent patches as simple as possible. Having to
>> rewrite the if statement in the next patch just clutters it up and makes the
>> real changes introduced by that patch less obvious
> 
> I think the code suggested by Junio may be cleaner ;)

Yes, I'll reroll with Junio's suggestion

> I may write as:
> 
> 	if (ignore_whitespace) {
> 		if (options.type == REBASE_APPLY)
> 			argv_array_push(...)
> 		else
> 			string_list_append(...)
> 	}
> 
> 	if (other_condition)
> 		do_something_else(...)
> 
> I don't know if it's cleaner or not.

It leads to a lot of repetition of ' && options.type == REBASE_APPLY' as
all the other conditions apart from --ignore-whitespace only need
handling for the apply backend here.

> I haven't tried applied it into real code.
> 
>>> Anyway, IIRC, --ignore-whitespace and --ignore-space-change has the
>>> same meaning, I think it's better to use the same option for both
>>> legs, no?
>>>
>>> I can understand the decision to use --ignore-whitespace as keeping
>>> the pass-through behavior of old code, but I think future maintenance
>>> is more important than that.
>>
>> I'm not sure how it affects future maintenance. The two different options
>> are for two different commands so I'm not sure it is worth the effort
> 
> I vaguely remember I was thinking about same option text in both leg
> would make the code easier for reasoning. And we can unify the
> recommendation for both backend. We will never strip
> --ignore-whitespace from git-apply, but it would be easier to always
> answer: "--ignore-space-change should be used to ignore space" when
> someone asks about it.
> 
> Typing this now makes me wonder if we should teach --ignore-space-change to
> git-rebase?

Possibly but not as part of this series which is about improving the
merge backend rather than adding new options to rebase itself

Best Wishes

Phillip

> 
> Thanks,
> 
> -- Danh
> 
>>
>> Best Wishes
>>
>> Phillip
>>
>>> I've tried changing ignore-whitespace to ignore-space-change and run
>>> make test
>>>
>>> It looks good to me (aka nothing failed _in my machine_),
>>> 4/5 and 5/5 is not applied, though.
>>>
>>>>   	if (strategy_options.nr) {
>>>>   		int i;
>>>> diff --git a/t/t3422-rebase-incompatible-options.sh b/t/t3422-rebase-incompatible-options.sh
>>>> index 50e7960702..55ca46786d 100755
>>>> --- a/t/t3422-rebase-incompatible-options.sh
>>>> +++ b/t/t3422-rebase-incompatible-options.sh
>>>> @@ -61,7 +61,6 @@ test_rebase_am_only () {
>>>>   }
>>>>   test_rebase_am_only --whitespace=fix
>>>> -test_rebase_am_only --ignore-whitespace
>>>>   test_rebase_am_only --committer-date-is-author-date
>>>>   test_rebase_am_only -C4
>>>> diff --git a/t/t3436-rebase-more-options.sh b/t/t3436-rebase-more-options.sh
>>>> new file mode 100755
>>>> index 0000000000..4f8a6e51c9
>>>> --- /dev/null
>>>> +++ b/t/t3436-rebase-more-options.sh
>>>> @@ -0,0 +1,60 @@
>>>> +#!/bin/sh
>>>> +#
>>>> +# Copyright (c) 2019 Rohit Ashiwal
>>>> +#
>>>> +
>>>> +test_description='tests to ensure compatibility between am and interactive backends'
>>>> +
>>>> +. ./test-lib.sh
>>>> +
>>>> +. "$TEST_DIRECTORY"/lib-rebase.sh
>>>> +
>>>> +# This is a special case in which both am and interactive backends
>>>> +# provide the same output. It was done intentionally because
>>>> +# both the backends fall short of optimal behaviour.
>>>> +test_expect_success 'setup' '
>>>> +	git checkout -b topic &&
>>>> +	test_write_lines "line 1" "	line 2" "line 3" >file &&
>>>> +	git add file &&
>>>> +	git commit -m "add file" &&
>>>> +
>>>> +	test_write_lines "line 1" "new line 2" "line 3" >file &&
>>>> +	git commit -am "update file" &&
>>>> +	git tag side &&
>>>> +
>>>> +	git checkout --orphan master &&
>>>> +	test_write_lines "line 1" "        line 2" "line 3" >file &&
>>>> +	git commit -am "add file" &&
>>>> +	git tag main
>>>> +'
>>>> +
>>>> +test_expect_success '--ignore-whitespace works with apply backend' '
>>>> +	test_must_fail git rebase --apply main side &&
>>>> +	git rebase --abort &&
>>>> +	git rebase --apply --ignore-whitespace main side &&
>>>> +	git diff --exit-code side
>>>> +'
>>>> +
>>>> +test_expect_success '--ignore-whitespace works with merge backend' '
>>>> +	test_must_fail git rebase --merge main side &&
>>>> +	git rebase --abort &&
>>>> +	git rebase --merge --ignore-whitespace main side &&
>>>> +	git diff --exit-code side
>>>> +'
>>>> +
>>>> +test_expect_success '--ignore-whitespace is remembered when continuing' '
>>>> +	(
>>>> +		set_fake_editor &&
>>>> +		FAKE_LINES="break 1" git rebase -i --ignore-whitespace \
>>>> +			main side &&
>>>> +		git rebase --continue
>>>> +	) &&
>>>> +	git diff --exit-code side
>>>> +'
>>>> +
>>>> +# This must be the last test in this file
>>>> +test_expect_success '$EDITOR and friends are unchanged' '
>>>> +	test_editor_unchanged
>>>> +'
>>>> +
>>>> +test_done
>>>> -- 
>>>> 2.27.0
>>>>
>>>
>