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

[Jeff King <peff@peff.net>]

On Sun, Apr 26, 2026 at 09:21:52PM +0200, Jonatan Holmgren wrote:

> I see the appeal of the overlapping-namespace approach for maximum compat.
> 
> My hesitation is that it introduces a config model where a single key
> (`alias.foo.bar`) no longer has a clear interpretation, but instead is
> implicitly treated as both a historical alias and structured data. That
> feels harder to reason about and document.
> 
> For the regression, I would lean toward a narrower compatibility rule:
> restore dotted aliases except where they collide with explicitly
> recognized structured keys (currently `command`). That keeps behavior
> predictable while still fixing the breakage.

Yeah, I agree with you here (and the rest of this email). My earlier
message was mostly about laying out the possible alternatives.

> One question: do we consider the historical dotted aliases something we
> want to preserve indefinitely, or just something to transition away from?
> My assumption has been that they were an accidental side-effect of the
> config parsing rather than a designed feature, but I agree they are now
> part of existing workflows and need to be handled carefully.

I think it would be OK to consider them a historical curiosity that may
eventually be removed, but without an active deprecation timeline. If
you do not need to work with older versions of Git it is already a good
idea to move to the new syntax because it prevents your alias being
caught up if further keys are added. It might be reasonable for the
documentation to note that (and of course also mention the downside,
which is that older versions of Git will not respect your alias).

We could eventually drop support, but I think it would have to be
either:

  1. In some distant version such that "pre-2.54" is considered ancient.

  2. At some version boundary where we declare a number of breaking
     changes. Git 3.0 is probably going to such a version, but I don't
     know if we have a concrete timeline (or how long we'd want a
     change to be in the "breaking changes" list in the build-up to that
     version).

There's a related question, too, about whether "alias.foo" (without
extra dots) could/should be dropped eventually. I don't see a particular
reason to do so, as the cost to carrying support is quite minimal.

-Peff