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

Re: [PATCH v2 6/9] branch: display publish branch

From
Felipe Contreras <felipe.contreras@gmail.com>
Date
Apr 12, 2014, 14:34 UTC
Message-ID
<53494f09531cc_c9914c7308a@nysa.notmuch>
In-Reply-To
<20140412112344.GA14820@sigill.intra.peff.net>
Jeff King wrote:
Show 12 quoted lines
> On Fri, Apr 11, 2014 at 08:48:01AM -0500, Felipe Contreras wrote:
> 
> > I think of @{publish} as "the branch the user has configured to push
> > to"; it overrides all other configurations (push.default and push
> > refspecs). I wouldn't mind having a @{push} *in addition* to @{publish}
> > that would have the behavior you mention, but for @{publish} I'm pretty
> > certain the behavior I want is that it maps *directly* to what the user
> > has configured.
> 
> I guess I don't understand why we need "branch.*.push" when we already
> have push refspecs that do the same thing (and are more powerful, as
> they can glob).
Really? I think it's pretty simple.
I have a configuration similar to the following
  [remote "gh"]
  	url = git@github.com:felipec/git.git
  [branch "master"]
  	pushremote = gh
  	push = refs/heads/master
  [branch "fc/master"]
  	pushremote = gh
  	push = refs/heads/fc/master
  [branch "up/publish"]
  	pushremote = gh
  	push = refs/heads/fc/publish
Now, if I didn't, I could create it easily with something like this:
  % git push -p gh master
  % git push -p gh fc/master
  % git push -p gh up/publish:fc/publish
How would that translate to push refspecs?
  [remote "gh"]
  	url = git@github.com:felipec/git.git
  	push = refs/heads/master:refs/heads/master
  	push = refs/heads/fc/master:refs/heads/fc/master
  	push = refs/heads/up/master:refs/heads/fc/publish
  [branch "master"]
  	pushremote = gh
  [branch "fc/master"]
  	pushremote = gh
  [branch "up/publish"]
  	pushremote = gh
So in theory it could be possible to make it work without branch.x.push.
If I run `git branch -v`, it would show the publish branch correctly.
  master cee0c27 [origin/master, gh/master] Git 1.9.1
However, if I have a configuration like this:
  [remote "gh"]
  	url = git@github.com:felipec/git.git
  	push = refs/heads/*:refs/heads/*

Git would still show the same publish branch, even though the user never explicitely told it do to so (e.g. with `git push -p`). To me this is not OK; if I haven't specifically set a publish branch, it shouldn't be shown.

And then, what happens when I do:
  % git branch --unset-upstream up/publish
Or:
  % git branch -d up/publish

Should Git remove the appropriate push refspec? What if that refspec was manually added by the user before the concept of the publish branch even existed?

To me using the refspec just adds more complications, and it's not symetric with @{upstream}. With branch.x.push, the symetry is very much there; the code is similar to @{upstream}, the configuration as well, and what the user expects too; it's much simpler. Also, the user can clearly see what are his manually configured refspecs, as opposed to the ones added by `git push -p`.

It's just neat.
-- 
Felipe Contreras
Previous: Jeff KingNext: Junio C Hamano
Message 13 of 34 in “Introduce publish tracking branch”
  1. 0/9 Introduce publish tracking branchFelipe Contreras, Apr 10, 2014
  2. 1/9 push: trivial reorganizationFelipe Contreras, Apr 10, 2014
  3. 2/9 Add concept of 'publish' branchFelipe Contreras, Apr 10, 2014
  4. 3/9 branch: allow configuring the publish branchFelipe Contreras, Apr 10, 2014
  5. 4/9 t: branch add publish branch testsFelipe Contreras, Apr 10, 2014
  6. 5/9 push: add --set-publish optionFelipe Contreras, Apr 10, 2014
  7. 6/9 branch: display publish branchFelipe Contreras, Apr 10, 2014
  8. Ramkumar RamachandraApr 10, 2014
  9. Felipe ContrerasApr 10, 2014
  10. Jeff KingApr 11, 2014
  11. Felipe ContrerasApr 11, 2014
  12. Jeff KingApr 12, 2014
  13. Felipe ContrerasApr 12, 2014
  14. Junio C HamanoApr 11, 2014
  15. Felipe ContrerasApr 11, 2014
  16. Jeff KingApr 12, 2014
  17. Felipe ContrerasApr 12, 2014
  18. Jeff KingApr 15, 2014
  19. Felipe ContrerasApr 18, 2014
  20. 7/9 sha1_name: cleanup interpret_branch_name()Felipe Contreras, Apr 10, 2014
  21. Ramkumar RamachandraApr 10, 2014
  22. 8/9 sha1_name: simplify track findingFelipe Contreras, Apr 10, 2014
  23. Ramkumar RamachandraApr 10, 2014
  24. Felipe ContrerasApr 10, 2014
  25. 9/9 sha1_name: add support for @{publish} marksFelipe Contreras, Apr 10, 2014
  26. Ramkumar RamachandraApr 10, 2014
  27. Felipe ContrerasApr 10, 2014
  28. Ramkumar RamachandraApr 10, 2014
  29. Felipe ContrerasApr 10, 2014
  30. Junio C HamanoApr 10, 2014
  31. Matthieu MoyApr 11, 2014
  32. Felipe ContrerasApr 11, 2014
  33. Matthieu MoyApr 11, 2014
  34. Felipe ContrerasApr 11, 2014

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.