git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: Implementing branch attributes in git config

From
Linus Torvalds <torvalds@osdl.org>
Date
May 8, 2006, 00:05 UTC
Message-ID
<Pine.LNX.4.64.0605071629080.3718@g5.osdl.org>
In-Reply-To
<1147037659.25090.25.camel@dv>
On Sun, 7 May 2006, Pavel Roskin wrote:
>
> I think a good implementation should allow any characters in the keys,
> even "=", because the key can be quoted.  Section names may disallow
> square brackets and dots.

That wouldn't help. The thing is designed to not only need no quoting (except for the _value_), it also is designed to have both section and key names ignore case. So you really aren't supposed to put things like branch names (which are potentially case-sensitive, depending on filesystem) in either.

And we depend on that (and I think it's important - users normally should _not_ care about capitalization)

So you'd need to literally create a different syntax if you want unquoted section naming.

> Such limitations make it unpractical to use branch names in section or
> key names.  I'd like to have it fixed.

Here's a possible syntax/patch. I actually think the quoting makes more sense in the section name, since you'll usually want several keys under each branch, so it makes sense to make the _branch_ be the section.

It basically makes it a special case if you have the section name be marked with quotes, like

	["XyZZy"]

and in that case it turns the _real_ section name into the string "branch.XyZZy", where the important part is that it does this without changing case or limiting the character set (but it will _not_ allow a newline) in any way.

So you could have something like
	["Origin"]
		URL = ...
		fetch = master
and it would just turn it into
	branch.Origin.url = ...
	branch.Origin.fetch = master
etc.

No, I'm not sure this is the best possible syntax. It's just a suggestion. And it's certainly simple enough.

The downside is that if you start using config files like this, you literally can't go back to older git versions. They'll refuse to touch such a config file (rather than just ignoring the new entries) and will exit with nasty messages. That might be unacceptable.

Instead of quoting with double-quotes, it might be ok to use some alternate syntax line "[:$branchname:]" which looks visually reasonable, and has the potential advantage that ':' is already an invalid character in a branch name, so you don't actually even need any quoting logic at all at that point.

I think the
	["branch"]
		...
syntax looks reasonably readable and clean.
		Linus
----
diff --git a/config.c b/config.c
index 41066e4..802e326 100644
--- a/config.c
+++ b/config.c
@@ -134,9 +134,44 @@ static int get_value(config_fn_t fn, cha
 	return fn(name, value);
 }
 
+static int get_branch_name(char *name)
+{
+	int baselen = 7;
+	int quote = 0;
+
+	memcpy(name, "branch.", 7);
+	for (;;) {
+		int c = get_next_char();
+		if (c == EOF)
+			return -1;
+		if (c == '\n')
+			return -1;
+		if (!quote) {
+			if (c == '"')
+				break;
+			if (c == ']')
+				return -1;
+			if (c == '\\') {
+				quote = 1;
+				continue;
+			}
+		}
+		name[baselen++] = c;
+		if (baselen > MAXNAME / 2)
+			return -1;
+	}
+	if (get_next_char() != ']')
+		return -1;
+	return baselen;
+}
+
 static int get_base_var(char *name)
 {
 	int baselen = 0;
+	int c = get_next_char();
+
+	if (c == '"')
+		return get_branch_name(name);
 
 	for (;;) {
 		int c = get_next_char();
Previous: Johannes SchindelinNext: Linus Torvalds
Message 4 of 75 in “Implementing branch attributes in git config”
  1. Pavel RoskinMay 7, 2006
  2. Junio C HamanoMay 7, 2006
  3. Johannes SchindelinMay 8, 2006
  4. Linus TorvaldsMay 8, 2006
  5. Linus TorvaldsMay 8, 2006
  6. Linus TorvaldsMay 8, 2006
  7. Johannes SchindelinMay 8, 2006
  8. Pavel RoskinMay 8, 2006
  9. Johannes SchindelinMay 8, 2006
  10. Pavel RoskinMay 8, 2006
  11. Junio C HamanoMay 8, 2006
  12. Johannes SchindelinMay 8, 2006
  13. Pavel RoskinMay 8, 2006
  14. seanMay 8, 2006
  15. Linus TorvaldsMay 8, 2006
  16. Pavel RoskinMay 8, 2006
  17. seanMay 8, 2006
  18. Pavel RoskinMay 8, 2006
  19. Linus TorvaldsMay 8, 2006
  20. Junio C HamanoMay 8, 2006
  21. seanMay 8, 2006
  22. Johannes SchindelinMay 8, 2006
  23. seanMay 8, 2006
  24. Junio C HamanoMay 8, 2006
  25. seanMay 8, 2006
  26. Daniel BarkalowMay 8, 2006
  27. seanMay 8, 2006
  28. Johannes SchindelinMay 8, 2006
  29. seanMay 9, 2006
  30. Johannes SchindelinMay 9, 2006
  31. Linus TorvaldsMay 9, 2006
  32. seanMay 9, 2006
  33. Junio C HamanoMay 9, 2006
  34. Linus TorvaldsMay 9, 2006
  35. Junio C HamanoMay 9, 2006
  36. Linus TorvaldsMay 9, 2006
  37. Junio C HamanoMay 9, 2006
  38. Linus TorvaldsMay 9, 2006
  39. seanMay 9, 2006
  40. Linus TorvaldsMay 9, 2006
  41. seanMay 9, 2006
  42. Linus TorvaldsMay 9, 2006
  43. Jakub NarebskiMay 9, 2006
  44. Johannes SchindelinMay 9, 2006
  45. Linus TorvaldsMay 9, 2006
  46. Junio C HamanoMay 9, 2006
  47. Linus TorvaldsMay 9, 2006
  48. seanMay 9, 2006
  49. seanMay 9, 2006
  50. Junio C HamanoMay 9, 2006
  51. seanMay 9, 2006
  52. Linus TorvaldsMay 10, 2006
  53. seanMay 10, 2006
  54. Linus TorvaldsMay 10, 2006
  55. Martin LanghoffMay 10, 2006
  56. Johannes SchindelinMay 10, 2006
  57. Linus TorvaldsMay 10, 2006
  58. Jakub NarebskiMay 10, 2006
  59. Martin LanghoffMay 10, 2006
  60. Linus TorvaldsMay 10, 2006
  61. Linus TorvaldsMay 11, 2006
  62. Jeff KingMay 11, 2006
  63. Jeff KingMay 11, 2006
  64. Martin LanghoffMay 11, 2006
  65. Johannes SchindelinMay 11, 2006
  66. Nicolas PitreMay 11, 2006
  67. Jakub NarebskiMay 11, 2006
  68. seanMay 10, 2006
  69. Junio C HamanoMay 11, 2006
  70. Martin WaitzMay 9, 2006
  71. Johannes SchindelinMay 9, 2006
  72. Johannes SchindelinMay 8, 2006
  73. Pavel RoskinMay 9, 2006
  74. seanMay 9, 2006
  75. Pavel RoskinMay 9, 2006

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.