From: Philip Oakley Date: Fri, 27 May 2022 12:35:03 GMT Subject: Re: [PATCH 1/3] rebase.c: state preserve-merges has been removed Message-ID: <4ff0622a-9b64-4200-e996-2d1875a52ec8@iee.email> In-Reply-To: <32e5088b-35a1-4e8c-098e-18c465a0a0bb@web.de> Hi René On 26/05/2022 22:27, René Scharfe wrote: > Am 26.05.22 um 22:33 schrieb Junio C Hamano: >> René Scharfe writes: >> >>>>> 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), >>> Anyway, the new help text explaining what the option once did is a bit >>> confusing. It would be better to focus on what it's doing now (nothing) >>> and/or why we still have it (for backward compatibility), I think. >> Do you mean that we should say "this option used to do such and such >> but it is now a no-op" after "(REMOVED)" label, instead of the above >> "this option does such and such"? I think "(REMOVED)" is a strong >> enough hint that lets us get away without saying "used to" and "but >> it is now a no-op", so I can accept both. >> >> Or do you mean we should say "(REMOVED) for backward compatibility, >> does nothing but errors out"? I would be less in faviour, then. >> Those who are curious enough to ask --help-all would find it more >> helpful if we said what it used to do. Otherwise they wouldn't be >> asking --help-all in the first place, no? > When I see an option labeled "REMOVED" then I get confused because a > thing that says it no longer exists is obviously lying That's a misunderstanding between the response to the command line option, and the described operation of the former sub-command/option. > -- a removed > option would simply not be listed. Here the feature is gone and its > option remains, but only reports an educational message now. The needed user response is more that educational. In this case (for the Series) they are in a Catch-22 situation, stuck in a no-man's land between a preserve merges that has been started, and a Git that won't proceed. Currently (prior to the series) Git will even refuse to abort.. > > Perhaps a better option help text would be something like "no longer > supported, consider using --rebase-merges instead"? We'll still need to say _what_ is no longer supported, to ensure the user has context. I'd agree with the suggestion aspect (Junio had commented similarly). I suspect this problem could be a long, slow burner. We so rarely remove capabilities like this, so it's tricky second guessing how users will react, or when they discover the problem. P.