Re: [PATCH 3/3] rebase: note `preserve` merges may be a pull config option

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

 



hi,
On 26/05/2022 10:50, Ævar Arnfjörð Bjarmason wrote:
> On Thu, May 26 2022, Philip Oakley via GitGitGadget wrote:
>
>> From: Philip Oakley <philipoakley@iee.email>
>>
>> The `--preserve-merges` option was removed by v2.35.0. However
>> users may not be aware that it is also a Pull option, and it is
>> still offered by major IDE vendors such as Visual Studio.
>>
>> Extend the `--preserve-merges` die message to also direct users to
>> the use of the `preserve` option in the `pull` config.
>>
>> Signed-off-by: Philip Oakley <philipoakley@iee.email>
>> ---
>>  builtin/rebase.c | 3 ++-
>>  1 file changed, 2 insertions(+), 1 deletion(-)
>>
>> diff --git a/builtin/rebase.c b/builtin/rebase.c
>> index aada25a8870..6fc0aaebbb8 100644
>> --- a/builtin/rebase.c
>> +++ b/builtin/rebase.c
>> @@ -1205,7 +1205,8 @@ int cmd_rebase(int argc, const char **argv, const char *prefix)
>>  			     builtin_rebase_usage, 0);
>>  
>>  	if (preserve_merges_selected)
>> -		die(_("--preserve-merges was replaced by --rebase-merges"));
>> +		die(_("--preserve-merges was replaced by --rebase-merges\n"
>> +			"Your `pull` configuration, may also invoke this option."));
>>  
>>  	if (action != ACTION_NONE && total_argc != 2) {
>>  		usage_with_options(builtin_rebase_usage,
> Ditto 2/3 about maybe die_message() + advise(). 
I'm not that enamoured about hiding die message details behind an advice
option. In this case it not meant to be a regular reminder type thing,
rather a one-off fix-it-forever sort of `advice'. At least that my
reasoning.

> In this case that has
> the slight advantace of allowing us to keep the existing translated
> string as-is.
>
> But also, is *our* pull configuration causing us to end up here?
Yes, but. The extra message is about fixing all places that the user may
have setup a config for using preserve-merges, not just here. The fact
that IDEs offer a menu for adding that setting makes it easy for users
to get into this.
I'd agree that pull already has detection for this, but I was looking to
avoid the 'fool me once, fool me twice' scenarios.

It could be dropped if thought over zealous.
>  I
> vaguely recall that being discussed (probably in answer to a question of
> mine) in the earlier round, or is this the IDE picking it up & invoking
> us like this?
>




[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