Thread (2 messages) flat view 2 messages, 2 authors, 2026-02-10

Re: [PATCH v2 2/2] alias: support non-alphanumeric names via subsection syntax

From: Junio C Hamano <hidden>
Date: 2026-02-10 19:47:26

Jonatan Holmgren [off-list ref] writes:
Git alias names are limited to alphanumeric characters and dashes
because config variable names are validated by iskeychar(). This
"ASCII alphanumeric", perhaps, as accented alphabet characters are
still alphanumeric ;-).  "because aliases are implemented as config
variable names" is probably an explanation that talks to readers in
terms closer to them (iskeychar() function is an implementation detail).
prevents non-English speakers from creating aliases in their native
languages.
True.
Add support for arbitrary alias names by using config subsections:

    [alias "förgrena"]
        command = branch

The subsection name is matched as-is (case-sensitive byte comparison),
while the existing definition without a subsection (e.g.,
"[alias] co = checkout") remains case-insensitive for backward
compatibility. This uses existing config infrastructure since
subsections already support arbitrary bytes, and avoids introducing
Unicode normalization.

Also teach the help subsystem about the new syntax so that "git help
-a" properly lists subsection aliases and the autocorrect feature can
suggest them. Use utf8_strwidth() instead of strlen() for column
alignment so that non-alphanumeric alias names display correctly.
Either move the last two hunks from [1/2] to this step, or make it a
separate patch [1.5/2] between this and the other steps, and explain
it as a change that breaks compatibility in a way that hopefully
would not affect anybody in practice.  The alias configuration
parser used to be overly loose and took "alias.<subsection>.<key>"
as defining an alias "<subsection>.<key>"; that change tightens the
parser and alias.<subsection>.<key> are silently ignored.  This step
then take alias.<subsection>.command to be defining a new-style
alias that can be invoked as "<subsection>", which is case sensitive
and is not limited to ASCII alphanumeric and dashes.
quoted hunk
Suggested-by: Jeff King <redacted>
Signed-off-by: Jonatan Holmgren <redacted>
---
 Documentation/config/alias.adoc | 44 +++++++++++++++++++++-----
 alias.c                         | 45 ++++++++++++++++++++++-----
 help.c                          | 12 +++++--
 t/t0014-alias.sh                | 55 +++++++++++++++++++++++++++++++++
 4 files changed, 137 insertions(+), 19 deletions(-)
diff --git a/Documentation/config/alias.adoc b/Documentation/config/alias.adoc
index 80ce17d2de..17a548cd64 100644
--- a/Documentation/config/alias.adoc
+++ b/Documentation/config/alias.adoc
@@ -1,12 +1,40 @@
 alias.*::
+alias.*.command::
+	Command aliases for the linkgit:git[1] command wrapper. Aliases
+	can be defined using two syntaxes:
++
+--
+1. Without a subsection, e.g., `[alias] co = checkout`. The alias
+   name is limited to alphanumeric characters and `-` (the same
+   limitation as configuration variable names), and is matched
+   case-insensitively.
+2. With a subsection, e.g., `[alias "name"] command = value`. The
+   alias name can contain any characters including UTF-8, and is
+   matched case-sensitively as raw bytes.
+--
++
+Examples:
++
+----
+# Without subsection
+[alias]
+    co = checkout
+    st = status
+
+# With subsection (allows UTF-8 and special characters)
+[alias "hämta"]
+    command = fetch
+[alias "gömma"]
+    command = stash
+----
++
+E.g. after defining `alias.last = cat-file commit HEAD`, the invocation
+`git last` is equivalent to `git cat-file commit HEAD`. To avoid
+confusion and troubles with script usage, aliases that
+hide existing Git commands are ignored except for deprecated
+commands.  Arguments are split by
+spaces, the usual shell quoting and escaping are supported.
+A quote pair or a backslash can be used to quote them.
 +
 Note that the first word of an alias does not necessarily have to be a
 command. It can be a command-line option that will be passed into the
diff --git a/alias.c b/alias.c
index c66a6095bb..cfd313ce5d 100644
--- a/alias.c
+++ b/alias.c
@@ -17,21 +17,50 @@ static int config_alias_cb(const char *key, const char *value,
 			   const struct config_context *ctx UNUSED, void *d)
 {
 	struct config_alias_data *data = d;
-	const char *p;
+	const char *subsection, *subkey;
+	size_t subsection_len;
 
-	if (!skip_prefix(key, "alias.", &p))
+	if (parse_config_key(key, "alias", &subsection, &subsection_len,
+			     &subkey) < 0)
 		return 0;
 
+	/*
+	 * Two config syntaxes:
+	 * - alias.name = value        (without subsection, case-insensitive)
+	 * - [alias "name"]
+	 *       command = value       (with subsection, case-sensitive)
+	 */
+	if (subsection) {
+		if (strcmp(subkey, "command"))
+			return 0;
This silently ignores

	[alias "foo"]
		bar = !date

which may or may not be a feature.  If the variable name is "help"
instead of "bar", it certainly is a feature to silently skip it, as
it is not inconceivable that we would add such a variable name in
the future, and because we won't be able to predict the future, not
limiting us to "help" but ignoring anything we do not understand
like this code does may probably be a good thing.  I dunno.
+	}
+
 	if (data->alias) {
-		if (!strcasecmp(p, data->alias)) {
+		int match;
+
+		if (subsection)
+			match = (strlen(data->alias) == subsection_len &&
+				 !strncmp(data->alias, subsection,
+					  subsection_len));
+		else
+			match = !strcasecmp(data->alias, subkey);
+
+		if (match) {
 			FREE_AND_NULL(data->v);
-			return git_config_string(&data->v,
-						 key, value);
+			return git_config_string(&data->v, key, value);
 		}
 	} else if (data->list) {
-		if (value)
-			string_list_append(data->list, p)->util =
-				xstrdup(value);
+		struct string_list_item *item;
+
+		if (!value)
+			return 0;
+
+		if (subsection)
+			item = string_list_append_nodup(data->list,
+				xmemdupz(subsection, subsection_len));
+		else
+			item = string_list_append(data->list, subkey);
+		item->util = xstrdup(value);
This still silently ignores

	[alias "foo"]
		command

which is a much more grave problem than ignoring alias.foo.bar in
the earlier part of this function.  We would want to preserve the
existing diagnosis on broken configuration.
quoted hunk
@@ -108,7 +109,7 @@ static void print_command_list(const struct cmdname_help *cmds,
 
 	for (i = 0; cmds[i].name; i++) {
 		if (cmds[i].category & mask) {
-			size_t len = strlen(cmds[i].name);
+			size_t len = utf8_strwidth(cmds[i].name);
 			printf("   %s   ", cmds[i].name);
 			if (longest > len)
 				mput_char(' ', longest - len);
@@ -492,7 +493,7 @@ static void list_all_cmds_help_aliases(int longest)
 	string_list_sort(&alias_list);
 
 	for (i = 0; i < alias_list.nr; i++) {
-		size_t len = strlen(alias_list.items[i].string);
+		size_t len = utf8_strwidth(alias_list.items[i].string);
 		if (longest < len)
 			longest = len;
 	}
@@ -590,8 +591,13 @@ static int git_unknown_cmd_config(const char *var, const char *value,
 
 	/* Also use aliases for command lookup */
 	if (!parse_config_key(var, "alias", &subsection, &subsection_len, &key)) {
-		if (!subsection)
+		if (subsection) {
+			if (!strcmp(key, "command"))
+				add_cmdname(&cfg->aliases, subsection,
+					    subsection_len);
+		} else {
 			add_cmdname(&cfg->aliases, key, strlen(key));
+		}
 	}
OK.  Alternatively, out of

	[alias "foo"]
		command = !echo foo
		bar = !echo bar

we _could_ list "foo" (a new style alias) and "foo.bar" (an old
style alias that we have been accepting forever by mistake) for
maximum backward compatibility.  I am still undecided if it is a
good idea.

Thanks.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help