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

Re: [1.8.0] Provide proper remote ref namespaces

From
Johan Herland <johan@herland.net>
Date
Feb 6, 2011, 22:12 UTC
Message-ID
<201102062312.51655.johan@herland.net>
In-Reply-To
<AANLkTi=gd5iu0i=ggqJC++N_rL+nU6RO9PNw=jMpT0NH@mail.gmail.com>
On Sunday 06 February 2011, Dmitry Potapov wrote:
Show 8 quoted lines
> On Sun, Feb 06, 2011 at 05:11:45PM +0100, Johan Herland wrote:
> > In practice, there is almost always one namespace (i.e. your repo
> > belongs to_ only one project with project-wide unique tags). However,
> > in any distributed_ system, the only-one-namespace is fundamentally a
> > myth.
> 
> By your logic git 1.7.4 is a myth, because I have not specified from
> what repository I pull it.

Yes, technically git 1.7.4 is a myth. However, by convention, we all agree what "v1.7.4" points to, and nobody seriously believe they can get away with pointing "v1.7.4" somewhere else.

The core of this discussion is where we want to place Git in the space between "technically correct" and "socially conventional", where the former means owning up to the fact that each repo really is its own namespace, and there's no way around that in a proper DVCS, and the latter means building social convention into our tools, thereby making it harder to deal with the few unconventional cases (like my two semi-related repos case).

AFAICS, my proposal does not harm the common case (unambiguous tags are still interpreted unambiguously, even if they may exist in multiple namespaces), while it _does_ help the uncommon case (by allowing ambiguous tags to co-exist in the same repo).

Granted, if we leave all tags in a single namespace, I can still work around this by manually futzing with the configured refspecs to create ad hoc namespaces. But I _really_ hate it when I'm forced to hack around the tool, because the tool thinks it "knows better".

> But, IMHO, it is a myth that having different
> namespaces solves the problem, because in _most_ cases, you really want
> to have a single namespace _semantically_, so you can communicate with
> other people using this tag name.

My proposal tries very hard to present a single namespace _semantically_ to the user in the common case (when tags are unambiguous). I'd even go as far as proposing that "git tag -l" should by default list only a single shortened tag name in the cases where there are multiple unambiguous alternatives.

Alternatively, I'd suggest a compromise (already mentioned elsewhere in this thread) where we add a config variable tags.preferredRemote (defaults to "origin") which allows you to directly select which namespace you consider official. You could even implement this as physically copying refs/remotes/${tag.preferredRemote}/tags/* into refs/tags/*.

Show 8 quoted lines
> > In that case it would be wrong of gitk to display "v1.0". Instead it
> > should_ display a longer, unambiguous name, e.g. "origin/v1.0".
> 
> But it is still ambiguous because my "origin" may be different from
> yours origin. It is only unambiguous when it look at it _locally_ but
> that makes it completely useless for communication with other people.
> One project should have only one version with the same tag regardless
> where it came from.

Again, you are setting "technical correctness" up against "social convention". Technically, _any_ ref name whatsoever is repo-specific and "completely useless for communication with other people". The only thing we can communicate unambiguously is SHA-1 object names. However, social conventions compel us to name our refs unambiguously and to use common sense when communicating, so that - in practice - everybody in the project knows exactly what is meant by "v1.0".

It seems our opinions differ on whether Git should try to _force_ this social convention on you, or rather stick to technical correctness (with a bias towards conventional behavior as long as there no ambiguities).

> I agree in your use case of semi-related projects you need separate
> namespaces. But I don't think it is how most people use git. It may
> be nice to have an option that will make tag namespace separate, but
> I do not think it should be default. Not until, it is widely tested.

Well, this _is_ the thread for discussing things "we would have done differently if we were writing Git from scratch". ;)

Still, you have yet to convince me exactly _what_ will in practice be horribly and user-visibly broken by this proposal. AFAICS, all the common use cases today will still work well with this proposal.

...Johan
-- 
Johan Herland, <johan@herland.net>
www.herland.net
Previous: Dmitry PotapovNext: Dmitry Potapov
Message 28 of 104 in “[1.8.0] Remote tag namespace”
  1. Nguyen Thai Ngoc DuyFeb 1, 2011
  2. Leo RazoumovFeb 1, 2011
  3. Marc BranchaudFeb 1, 2011
  4. Nguyen Thai Ngoc DuyFeb 1, 2011
  5. Marc BranchaudFeb 2, 2011
  6. Jeff KingFeb 1, 2011
  7. Sverre RabbelierFeb 1, 2011
  8. [1.8.0] Provide proper remote ref namespacesJohan Herland, Feb 2, 2011
  9. Santi BéjarFeb 2, 2011
  10. Johan HerlandFeb 2, 2011
  11. Santi BéjarFeb 2, 2011
  12. Nguyen Thai Ngoc DuyFeb 3, 2011
  13. Johan HerlandFeb 3, 2011
  14. Nguyen Thai Ngoc DuyFeb 3, 2011
  15. Johan HerlandFeb 3, 2011
  16. Santi BéjarFeb 3, 2011
  17. Nguyen Thai Ngoc DuyFeb 3, 2011
  18. Junio C HamanoFeb 4, 2011
  19. Johan HerlandFeb 5, 2011
  20. Kevin P. FlemingFeb 5, 2011
  21. Dmitry PotapovFeb 5, 2011
  22. Johan HerlandFeb 6, 2011
  23. Dmitry PotapovFeb 6, 2011
  24. Nicolas PitreFeb 6, 2011
  25. Dmitry PotapovFeb 6, 2011
  26. Johan HerlandFeb 6, 2011
  27. Dmitry PotapovFeb 6, 2011
  28. Johan HerlandFeb 6, 2011
  29. Dmitry PotapovFeb 7, 2011
  30. Bernhard R. LinkFeb 7, 2011
  31. Dmitry PotapovFeb 8, 2011
  32. Matthieu MoyFeb 6, 2011
  33. Johan HerlandFeb 6, 2011
  34. Matthieu MoyFeb 6, 2011
  35. Johan HerlandFeb 7, 2011
  36. Jeff KingFeb 7, 2011
  37. Johan HerlandFeb 7, 2011
  38. Sverre RabbelierFeb 7, 2011
  39. Johan HerlandFeb 7, 2011
  40. Nguyen Thai Ngoc DuyFeb 7, 2011
  41. Jeff KingFeb 7, 2011
  42. Johan HerlandFeb 8, 2011
  43. Jakub NarebskiFeb 11, 2011
  44. Johan HerlandFeb 13, 2011
  45. Junio C HamanoFeb 14, 2011
  46. Johan HerlandFeb 14, 2011
  47. Jakub NarebskiFeb 14, 2011
  48. Junio C HamanoFeb 14, 2011
  49. Re* [1.8.0] Provide proper remote ref namespacesJunio C Hamano, Feb 14, 2011
  50. Jay SoffianFeb 14, 2011
  51. Sverre RabbelierFeb 14, 2011
  52. Jay SoffianFeb 14, 2011
  53. Jonathan NiederFeb 14, 2011
  54. Jay SoffianFeb 14, 2011
  55. Jonathan NiederFeb 14, 2011
  56. Matthieu MoyFeb 14, 2011
  57. Jeff KingFeb 14, 2011
  58. Sverre RabbelierFeb 14, 2011
  59. Jonathan NiederFeb 14, 2011
  60. Junio C HamanoFeb 14, 2011
  61. Junio C HamanoFeb 14, 2011
  62. Johan HerlandFeb 15, 2011
  63. Junio C HamanoFeb 15, 2011
  64. push.default: Rename 'tracking' to 'upstream'Johan Herland, Feb 16, 2011
  65. Junio C HamanoFeb 16, 2011
  66. Matthieu MoyFeb 16, 2011
  67. Martin von ZweigbergkFeb 16, 2011
  68. Jakub NarebskiFeb 16, 2011
  69. Matthieu MoyFeb 16, 2011
  70. Sverre RabbelierFeb 16, 2011
  71. Junio C HamanoFeb 16, 2011
  72. Sverre RabbelierFeb 16, 2011
  73. Junio C HamanoFeb 16, 2011
  74. Martin von ZweigbergkFeb 18, 2011
  75. Martin von ZweigbergkFeb 18, 2011
  76. Bernhard R. LinkFeb 16, 2011
  77. Jakub NarebskiFeb 14, 2011
  78. Marc BranchaudFeb 14, 2011
  79. Nicolas PitreFeb 14, 2011
  80. Junio C HamanoFeb 14, 2011
  81. Nicolas PitreFeb 14, 2011
  82. Sverre RabbelierFeb 14, 2011
  83. Matthieu MoyFeb 7, 2011
  84. Dmitry PotapovFeb 7, 2011
  85. Nicolas PitreFeb 5, 2011
  86. Jeff KingFeb 5, 2011
  87. Nicolas PitreFeb 5, 2011
  88. Johan HerlandFeb 5, 2011
  89. Junio C HamanoFeb 6, 2011
  90. Marc BranchaudFeb 7, 2011
  91. Junio C HamanoFeb 7, 2011
  92. Nicolas PitreFeb 7, 2011
  93. Jeff KingFeb 7, 2011
  94. Nicolas PitreFeb 7, 2011
  95. Jeff KingFeb 7, 2011
  96. Nicolas PitreFeb 7, 2011
  97. Jeff KingFeb 7, 2011
  98. Johan HerlandFeb 1, 2011
  99. Nicolas PitreFeb 7, 2011
  100. Dmitry PotapovFeb 8, 2011
  101. Johan HerlandFeb 8, 2011
  102. Enrico WeigeltFeb 8, 2011
  103. Junio C HamanoFeb 8, 2011
  104. Johan HerlandFeb 9, 2011

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.