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 10, 2006, 02:08 UTC
Message-ID
<Pine.LNX.4.64.0605091854380.3718@g5.osdl.org>
In-Reply-To
<BAYC1-PASMTP037EBB0237B35C5F92FB0BAEAE0@CEZ.ICE>
On Tue, 9 May 2006, sean wrote:
Show 11 quoted lines
> On Tue, 9 May 2006 17:17:58 -0700 (PDT)
> Linus Torvalds <torvalds@osdl.org> wrote:
> 
> > And it's _not_ that hard to make repo-config do the right thing.
> > 
> > Here's a pretty lightly tested patch (on top of my previous one) that does 
> > exactly that.
> 
> So every mutli-part section is going to be of the form:
> 
>   [section "big long opaque string"]

That's what my stupid patch does now. It seems to work well for all cases, but if we were to care, we could have some special heuristics for different section names (ie "if subsection is all lower-case alphanumerics, and the section name is one of the following, use the old-fashioned format").

I don't see _why_ we'd ever do that, but we certainly _could_, if it were to make more sense that way for some section name.

However, if you already use a syntax like
	[section.subsection]
		key = 1
and then do
	git-repo-config --replace-all section.subsection.new 2
it will actually keep the old section header, so you'll end up with
	[section.subsection]
		key = 1
		new = 2

but if you create a _new_ subsection (and since subsections are now case sensitive, this example is a "new" subsection):

	git-repo-config --replace-all section.SubSection.new 3
you will now have
	[section.subsection]
		key = 1
		new = 2
	[section "SubSection"]
		new = 3

(ie notice how it did _not_ replace the old "section.subsection.new", because of how this is a _different_ subsection due to the subsectin rules, and notice how it will always create the new subsection with quotes).

So you _can_ continue to use the old subsection format, and it will work the way it always did, except for the fact that it would now be deprecated (if there were any multi-level users, which I don't think there are), and it is now case-sensitive (which makes sense in the new format with "" around it, but is illogical in the old deprecated one).

> It seems to handle everything, you have me convinced.

Hey, it was fun, and the only ugly part was the write-out of the quoted format.

And it should be perfectly easy to use. Modulo double-quotes in branch names, you can do trivial things like

	git repo-config "branch.$branchname.remote" "git://git.kernel.org/..."
and it will do the obvious thing.

My one complaint is that I think we should add an empty line for the case where we add a new sub-section to the end of a file. That's not a new problem, but that was really the only visually ugly part I noticed during testing.

You _can_ be user-friendly and machine-parseable at the same time!
			Linus
Previous: seanNext: Martin Langhoff
Message 54 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.