Re: [PATCH 1/3] rebase.c: state preserve-merges has been removed

["Ævar Arnfjörð Bjarmason" <avarab@gmail.com>]

On Thu, May 26 2022, René Scharfe wrote:

> Am 26.05.22 um 11:40 schrieb Ævar Arnfjörð Bjarmason:
>>
>> On Thu, May 26 2022, Philip Oakley via GitGitGadget wrote:
>>
>>> From: Philip Oakley <philipoakley@iee.email>
>>>
>>> Since feebd2d256 (rebase: hide --preserve-merges option, 2019-10-18)
>>> this option is now removed as stated in the subsequent release notes.
>>>
>>> Fix the option tip.
>>>
>>> Signed-off-by: Philip Oakley <philipoakley@iee.email>
>>> ---
>>>  builtin/rebase.c | 2 +-
>>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/builtin/rebase.c b/builtin/rebase.c
>>> index 7ab50cda2ad..6ce7e98a6f1 100644
>>> --- a/builtin/rebase.c
>>> +++ b/builtin/rebase.c
>>> @@ -1110,7 +1110,7 @@ int cmd_rebase(int argc, const char **argv, const char *prefix)
>>>  			PARSE_OPT_NOARG | PARSE_OPT_NONEG,
>>>  			parse_opt_interactive),
>>>  		OPT_SET_INT_F('p', "preserve-merges", &preserve_merges_selected,
>>> -			      N_("(DEPRECATED) try to recreate merges instead of "
>>> +			      N_("(REMOVED) try to recreate merges instead of "
>>>  				 "ignoring them"),
>>>  			      1, PARSE_OPT_HIDDEN),
>>>  		OPT_RERERE_AUTOUPDATE(&options.allow_rerere_autoupdate),
>>
>> I have some local patches for this more generally, but for
>> PARSE_OPT_HIDDEN options we never do anything with the "argh" field,
>> i.e. it's only used for showing the "git <cmd> -h" output, and if it's
>> hidden it won't be there.
>
> Hidden options are shown if you use --help-all instead of -h.
>
> OPT_SET_INT_F always sets the struct option member "argh" to NULL.  The
> string changed above is the "help" member, not "argh".
>
>> So there's no point in changing this string, nor to have translators
>> focus on it, it'll never be used.
>>
>> This series shouldn't fix the general issue (which parse-options.c
>> should really be BUG()-ing about, after fixing the existing
>> occurances. But For this one we could just set this to have a string of
>> "" or something, only the string you're changing in 3/3 will be seen by
>> anyone.
>
> What is the general issue?

You're right. I'd missed that case with --help-all, and remembered
briefly testing where we used the string before in some WIP code.

Looking at it again I think I tried NULL-ing a few and running the tests
with SANITIZE=address or something, which in this case it looks like
we'd 100% pass with. I.e. we have zero test coverage for that subsequent
NULL dereference.

Sorry about the noise. I'll add some tests for this case in some
parse-options.c sanity checking tests/patches I'm planning to submit at
some point.