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

On 9/14/26 15:03, Karthik Nayak wrote:

Patrick Steinhardt [off-list ref] writes:

quoted

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