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

From: Jeff King <peff@peff.net>
Date: Apr 26, 2026, 23:01 UTC
Message-ID: <20260426230125.GA218434@coredump.intra.peff.net>
In-Reply-To: <4a130a23-fa32-460b-a338-409d85d18166@jontes.page>

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

Show 11 quoted lines

> 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.

Show 5 quoted lines

> 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