Re: [PATCH v3 01/13] parse-options: allow for hidden aliases

[Kaartic Sivaraam <kaartic.sivaraam@gmail.com>]

On 9/14/26 15:03, Karthik Nayak wrote:
> Patrick Steinhardt <ps@pks.im> writes:
> 
>> The `OPT_ALIAS()` option can be used to create an exact alias that maps
>> one option name to the same semantics as another option name. This
>> option type is especially useful when deprecating an old name in favor
>> of a new one. But curiously enough, we don't have the infrastructure in
>> place to properly support this use case because we don't expose the
>> ability to hide the alias via `PARSE_OPT_HIDDEN`.
>>
> 
> If we're going to hide the alias, do we need to even use an alias?
> 
> [snip]
> 
> Perhaps it doesn't make sense to add flags to OPT_ALIAS() at all? But
> this is indeed an alias and seems like the correct option to use, but
> feels wasted. I'm okay to keep it as is.
> 

Just some food for thought. There are a couple of other instances where 
we are currently using OPT_ALIAS to represent the deprecated variant of 
an option. They are:

   1. `--recursive` is a deprecated alias of  `--recurse-submodule` in
      `git clone`

      cf. bb62e0a99f (clone: teach --recurse-submodules to optionally
      take a pathspec, 2017-03-17) and 5c387428f1 (parse-options: don't
      emit "ambiguous option" for aliases, 2019-04-29)

   2.  `--negotiation-tip` is a deprecated alias of
       `--negotiation-restrict` in `git fetch`

       cf. 1a445fc60b (fetch: add --negotiation-restrict option,
       2026-05-19)

       Note: The documentation clarifies that --negotiation-restrict is
       the preferred variant but does not mention about deprecation.

Since they are not hidden, the deprecated variants still show up in the 
help output of those commands. So, we appear to be doing fine with a 
public alias so far. So, may be it is not a big deal if we expose the 
deprecated option publicly?

-- 
Sivaraam