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 14, 2011, 09:18 UTC
Message-ID
<201102141018.46527.johan@herland.net>
In-Reply-To
<7vfwrrukzq.fsf@alter.siamese.dyndns.org>
On Monday 14 February 2011, Junio C Hamano wrote:
Show 20 quoted lines
> Johan Herland <johan@herland.net> writes:
> > Yes, replicating existing behavior w/explicit refspecs would look like: 
> >   [remote "origin"]
> >   
> >         url = git://git.example.com/repo.git
> >         fetch = +HEAD:refs/remotes/origin/HEAD
> >         fetch = +refs/heads/*:refs/remotes/origin/*
> >         fetch = ~refs/tags/*:refs/tags/*
> 
> While this is fine, I am not sure about the "HEAD" part.  Most of the
> protocol do not convey which branch HEAD points at (instead "clone" has
> to guess), which eventually needs to be fixed.  Incremental updates via
> "fetch" does not touch "HEAD" at all by design; unlike the real branch
> heads "remotes/origin/$branch" that are used to keep copies of what are
> at the remote, "remotes/origin/HEAD" is meant to be used by the local
> repository to designate which of the remote branch is considered the
> primary branch from local repository owner's point of view, primarily so
> that you can say "origin" locally to mean "origin/next" by setting the
> symref origin/HEAD to point at it.  In that sense, the guess made by
> "clone" is only used to give an initial value.

Ah, ok. I've misunderstood the purpose of "remotes/origin/HEAD" then. Feel free to remove that refspec line from my proposal, and leave it as a special-purpose thing set up by clone (and maintained by the user thereafter).

Still (as I think was recently discussed in another thread), the existence of remotes/origin/HEAD _does_ cause problems if the origin remote also has a branch called "refs/heads/HEAD" (which would collide when fetched into the local repo).

Show 13 quoted lines
> > FTR, my new/proposed refspecs would look like this:
> >   [remote "origin"]
> >   
> >         url = git://git.example.com/repo.git
> >         fetch = +HEAD:refs/remotes/origin/HEAD
> >         fetch = +refs/heads/*:refs/remotes/origin/heads*
> >         fetch = ~+refs/tags/*:refs/remotes/origin/tags/*
> >       
> >       ( fetch = +refs/notes/*:refs/remotes/origin/notes/* )
> >       ( fetch = +refs/replace/*:refs/remotes/origin/replace/* )
> 
> I think you meant "refs/remotes/origin/heads/*" (note the slash) on the
> RHS of the branch refspecs.
Indeed. Thanks for pointing out the typo.
> How's that different from refs/*:refs/remotes/origin/* by the way?

It's not, except that "refs/*:refs/remotes/origin/*" would fetch a too-large superset. E.g. it would fetch "refs/remotes/third-party/heads/foo" into "refs/remotes/origin/remotes/third-party/heads/foo", which we probably don't want.

> Also
> if you give tags a totally separate namespace, I don't see much reason to
> still give it the "auto-follow" semantics.  It is far simpler to explain
> if you just fetch all of them and be done with it, no?

Agreed. Also, to quote Peff in http://thread.gmane.org/gmane.comp.version- control.git/160503/focus=160726 :

"Now you could argue that auto-follow is not worth the effort. It is somewhat confusing, and I can't think of a time when it ever actually reduced the set of objects I was fetching (as opposed to just fetching all tags). But maybe others have use cases where it matters."

So if nobody disagree, I would have no problem with dropping the leading "~" from the refspec, thus disabling auto-following (tracking all tags explicitly instead).

Show 23 quoted lines
> > Yes, to me it seems intuitive that when you specify <URL> (even if
> > <URL> corresponds to an existing remote) you do NOT update
> > remote-tracking refs, but if you use <remote>, you should ALWAYS
> > update remote-tracking refs. Others may disagree.
> 
> One argument for disagreement used to be that an explicit fetch of a
> single branch was a deliberate way to avoid updating the tracking branch
> before examining what has been changed (i.e. "git fetch origin master"
> followed by "git log origin/master..FETCH_HEAD" and hopefully followed by
> "git pull origin" or somesuch).  But that was before reflog was adopted
> as a reliable safety measure, and I don't think people should rely on
> that behaviour anymore.
> 
> I would actually make an even stronger point that people should not base
> their workflow on keeping remote tracking refs deliberately stale, which
> is exactly the "feature" was meant to be used for.  What has happened on
> the other end has already happened whether you like it or not, and there
> is no point in your locally pretending that it didn't happen.  If you
> don't like the latest update there, you go talk to the party that control
> the remote and rectify the situation with them.  It may involve pushing a
> reverting or correcting commit over there, or in the worst case you
> simply stop pulling from them, forking the project in effect at that
> point.
Agreed.
Show 19 quoted lines
> > It may seem so, but in my experience it doesn't really work perfectly:
> > Even if I fully control the repo I push to, I still want precise
> > control over what I push there. Sometimes I may working on 'next' and
> > 'master' in parallel, and I might have finished and tested some
> > bugfixes on 'master', while I still have unfinished/untested stuff on
> > 'next'.
> 
> Yes, I do this all the time and I often say "git push ko maint master"
> (ko is my name for the k.org repo).  I however don't feel inconvenienced
> by it precisely because when I make such a push, I _know_ that I want to
> push only these two branches.  Saying "only these two branches"
> explicitly from the command line, and seeing only these two branches go
> out, are very assuring to me.  I usually try to be much more organized
> to make sure all four integration branches satisfy certain preconditions
> before pushing, and I say "git push ko" only after I make sure they do.
> 
> I consider it is a good UI design to force myself to type more when I am
> doing something un(der)disciplined and to let me type less when I am
> following a good project hygiene.

I don't doubt that the current behavior works well for you (otherwise I expect you would have changed it). However, what I've seen at $dayjob is that more inexperienced users will often push right after committing, and at that time they're still very much in the "working-on-one-branch" state of mind (as opposed to the "administering-multiple-branches" state of mind), so when they follow up a "git commit" with a "git push" they're surprised (or worse: oblivious) to the fact that "git push" can push multiple branches.

I guess it comes down to whether you fundamentally consider "git push" something that pushes multiple _branches_, or something that pushes multiple _commits_. And for the latter of those groups push.default == "matching" is inherently more "dangerous" than for the former. (Granted, me telling everyone to use push.default == "tracking" probably doesn't help them in discovering "git push"'s ability to update multiple branches.)

Have fun! :)
...Johan
-- 
Johan Herland, <johan@herland.net>
www.herland.net
Previous: Junio C HamanoNext: Jakub Narebski
Message 46 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.