Re: [PATCH] alias: restore support for simple dotted aliases

From: Jeff King <peff@peff.net>
Date: Apr 25, 2026, 23:29 UTC
Message-ID: <20260425232916.GA29816@coredump.intra.peff.net>
In-Reply-To: <40408c99-7e2a-4cf6-b9b2-6d0e0da3b2c5@jontes.page>

On Sat, Apr 25, 2026 at 11:57:24AM +0200, Jonatan Holmgren wrote:

> That is a challenge we are going to have to consider. I think reserving
> `command` is a worthwhile compromise, but obviously we cannot do that for
> arbitrary future keys such as `help`, `hidden`, etc.

We don't necessarily have to reserve them. When we see alias.foo.bar, we could consider it as both alias "foo.bar" and the "bar" key of alias "foo", without regard to what is in "bar" (i.e., whether it is "command" or "help", etc). I.e., don't "fall back" but allow two overlapping namespace.s

That is the most backwards-compatible thing we could do, but does create some interesting situations.

If you define alias.foo.command with the intent to allow "git foo", that is also creating the identical alias "git foo.command". Probably nobody cares too much, as if you did not mean to make "foo.command" you would never invoke it. We'd probably want to omit it when listing aliases, though.

If we later introduce alias.foo.help, the same thing applies but with a twist. Running "git foo.help" will invoke that key as an alias command, but it is probably not a sensible command in the first place. But again, I'm not sure why anybody would try to do so.

That said, I don't think reserving "command" or even some future names is that painful in the long run. The three-level syntax is a superset of the old functionality, and in general the best solution will be for users to convert their old aliases to it. The benefits of providing the fallback compatibility are:

  1. Users can avoid having to do anything at all. And that will still
     be true for the majority, unless they happen to have a three-level
     alias that ends with ".command" (for now) or eventually ".help",
     etc. We don't have any hard data, but I have to imagine that the
     numbers here are vanishingly small.

  2. Cross-version compatibility. You can't use alias.pull.sub.command
     in Git v2.53 and older, so it's otherwise impossible to have config
     that works both there and with v2.54.

     But as time goes on, wanting to cross that version boundary becomes
     less and less likely. If we we eventually introduce ".help" and it
     breaks somebody foo.help alias, suggesting alias.foo.help.command
     will work all the way back to Git v2.54, which may be sufficient.

Show 9 quoted lines

> One possible compromise would be to reserve `command` and `alias-*`, as
> neither seems very likely to exist in users' historical alias names.
> 
> A new namespace makes the most sense from a namespace-pollution point of
> view, but I struggle to see that as good UX. Even a separate namespace
> only for alias metadata would make more sense to me than moving aliases
> entirely, since subsection aliases with just `command` will likely be far
> more common than any future metadata keys, but this is not something I see
> as a good solution either.

Yeah. Obviously a totally separate namespace makes all of this go away, but it feels like we are sacrificing the experience going forward in order to accommodate some fairly unlikely historical clashes.

-Peff