Re: [PATCH v6 2/4] alias: prepare for subsection aliases

From: Kristoffer Haugsbakk <kristofferhaugsbakk@fastmail.com>
Date: Feb 18, 2026, 16:21 UTC
Message-ID: <81e6846c-457b-438d-99b5-6412007049dd@app.fastmail.com>
In-Reply-To: <20260218145214.581460-3-jonatan@jontes.page>

On Wed, Feb 18, 2026, at 15:52, Jonatan Holmgren wrote:

Show 10 quoted lines

> Switch git_unknown_cmd_config() from skip_prefix() to
> parse_config_key() for alias parsing. This properly handles the
> three-level config key structure and prepares for the new
> alias.*.command subsection syntax in the next commit.
>
> This is a compatibility break: the alias configuration parser used
> to be overly permissive and accepted "alias.<subsection>.<key>" as
> defining an alias "<subsection>.<key>". With this change,
> alias.<subsection>.<key> entries are silently ignored (unless <key>
> is "command", which will be given meaning in the next commit).

Unrelated to this change. I was wondering if it makes sense to use a trailer for commits that break compatibility? However unrealistic it might be that the break ends up mattering in practice.

Authors might use different terms and phrases in their commit messages, like

• Breaking change • Compatibility break • Hysterical raisins

And the commit message might be using these terms to describe how it breaks compatibility or how it *avoids* doing so.

Show 7 quoted lines

>
> This behavior was arguably a bug, since config subsections were never
> intended to work this way for aliases, and aliases with dots in their
> names have never been documented or intentionally supported.
>
> Signed-off-by: Jonatan Holmgren <jonatan@jontes.page>
>[snip]