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

Re: [PATCH v2 0/9] Introduce publish tracking branch

From
Felipe Contreras <felipe.contreras@gmail.com>
Date
Apr 11, 2014, 19:16 UTC
Message-ID
<53483f7984cb8_2c1f6e72ecc0@nysa.notmuch>
In-Reply-To
<vpqd2gng4nl.fsf@anie.imag.fr>
Matthieu Moy wrote:
Show 14 quoted lines
> Felipe Contreras <felipe.contreras@gmail.com> writes:
> 
> > My patch series only affects push.default=simple, perhaps you have a
> > different configuration.
> 
> Good catch. I have push.default=upstream (essentially for compatibility
> with old Git versions, I'd prefer simple actually).
> 
> > Maybe we want the publish branch to override any push.default, so:
> 
> Not sure actually. If a user says "push.default=upstream", it seems
> weird to push to something other than upstream indeed. What's clear to
> me is that your patch in its current form clearly makes "simple" a much
> better default than "upstream" (good news, it it the default!).

As you said in another email; that's just the default. If the user explicitely told Git to use certain branch (git push -p), Git should use that branch.

Show 14 quoted lines
> That said, the advice given by "git status" is clearly wrong:
> 
> > >   $ git status
> > >   On branch master
> > >   Your branch is ahead of 'origin/new' by 4 commits.
> > >     (use "git push" to publish your local commits)
> 
> It should say (use "git push origin new" to publish your local commits)
> with push.default=upstream and the current behavior of the patch.
> 
> Perhaps argumentless "git push" could warn when push.default=upstream
> and branch.<name>.publish is configured, I'm not sure.
> 
> Sorry, more questions and "I'm not sure" than actual suggestion :-(.
I believe in v3 of the patch series "git push" will actually do it correctly.
Cheers.
-- 
Felipe Contreras
Previous: Matthieu Moy
Message 34 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.