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

Re: Not pushing all branches?

From
Junio C Hamano <gitster@pobox.com>
Date
Mar 13, 2009, 20:02 UTC
Message-ID
<7v4oxxgpil.fsf@gitster.siamese.dyndns.org>
In-Reply-To
<43d8ce650903130125m6335d189obbcdb86ec9036083@mail.gmail.com>
John Tapsell <johnflux@gmail.com> writes:
Show 12 quoted lines
> 2009/3/13 Peter Krefting <peter@softwolves.pp.se>:
>> Hi!
>>
>> Doing "git push remote" pushes all my local branches by default. Is there a
>> way to set it to *not* do that, and (for this particular remote repository)
>> just push the current branch?
>
>> Or failing that, not allow me to run "git
>> push" without specifying a branch?
>
> I've been pushing for this behaviour, and there was a patch a few days
> ago to do this.  I'm not sure if it is/will be committed.
The current status of the series is roughly as follows:
 * Finn Arne sent out a 6 patch series that consists of:
   0e118fe remote: Make "-" an alias for the current remote
   5a18380 New config option push.default
   0b9dcb9 git push: New options --matching and --current
   bf8552b git push: Display warning on unconfigured default push
   cf9d5ab git push: Document that "nothing" is the future push default
   3c2bcc2 git push: Change default for "git push" to nothing.
 * The main topic of the series are patches 2, 4, 5, 6:
   - Introduce a new configuration push.default;
   - Issue a warning when push.default is not set and 'git push' is run
     without saying what refspecs to push, and tell the users that the
     warning can be squelched by setting the configuration (set it to
     'matching' to keep the traditional, 'nothing' to get what Peter
     wants);
   - Reword the warning that the default will change to 'nothing';
   - Switch the default to 'nothing'.
   Which is a reasonable transition plan _if_ we were to change the
   default (except that I think the last one should still keep giving
   warning for people who learned git from the current documentation and
   the start using it after the default is changed).
   If you are changing the default, you have to make people who like the
   current "matching" behaviour suffer no matter how you go about it.  The
   above "start warning early, give chance to people to say 'I want to
   keep my default' before the default changes, and then finally change
   the default" would ease the pain of transition for them.  And the
   configuration option will help people who want new default to set it
   right away.
 * The series is queued in 'pu' for now, as it has a few issues (see mail
   archive for discussions):
   - The first "-" one; even though it may be useful to be able to say
     "the remote the current branch is associated with by default", using
     "-" as a short-hand for that might be harmful to the long term UI
     health, and further study was requested, which hasn't been responded
     yet.
   - The third "--matching/--current" one; --matching is unnecessary as we
     already have ":", --current turns out to be different from HEAD and
     is misnamed.  There also was somebody with an opinion that --current
     adds unnecessary complexity only to encourage a wrong workflow.
   In any case, these two do not have anything to do with the issue that
   "'matching refs' behaviour of a lazy 'git push' that does not say what
   refspecs to push is not always a useful default", and should be done as
   separate patches.  They should come after the dust settles after either
   applying the first two of the main part of the series or deciding to
   drop the main part of the series.
   Also the last one needs to adjust the tests because majority of them
   rely on the current 'matching' behaviour.  As the series lacks it,
   merging it all to 'pu' would make the result not pass the test suite,
   and I excluded the last few patches from 'pu' for now.
   The size of such a patch would be a rough indication how much pain you
   are proposing to incur on existing users.
 * Finn Arne sent the first one of a "replacement" patch series, which I
   looked at, but haven't had time to actually replace the ones that are
   queued in 'pu' (and I haven't seen the second and subsequent ones yet,
   so there is no rush on my end to do so at this moment).
Previous: Johannes SchindelinNext: Miles Bader
Message 13 of 27 in “Not pushing all branches?”
  1. Peter KreftingMar 13, 2009
  2. Imran M YousufMar 13, 2009
  3. Peter KreftingMar 13, 2009
  4. Johannes SchindelinMar 13, 2009
  5. Finn Arne GangstadMar 13, 2009
  6. John TapsellMar 13, 2009
  7. Johannes SchindelinMar 13, 2009
  8. John TapsellMar 13, 2009
  9. Johannes SchindelinMar 13, 2009
  10. John TapsellMar 13, 2009
  11. Michael J GruberMar 13, 2009
  12. Johannes SchindelinMar 13, 2009
  13. Junio C HamanoMar 13, 2009
  14. Miles BaderMar 14, 2009
  15. Jeff KingMar 17, 2009
  16. Jeff KingMar 13, 2009
  17. git-push.txt: describe how to default to pushing only current branchChris Johnsen, Mar 14, 2009
  18. Junio C HamanoMar 14, 2009
  19. Jeff KingMar 14, 2009
  20. Jeff KingMar 14, 2009
  21. Chris JohnsenMar 15, 2009
  22. Chris JohnsenMar 15, 2009
  23. Jeff KingMar 17, 2009
  24. Junio C HamanoMar 14, 2009
  25. Jeff KingMar 14, 2009
  26. Junio C HamanoMar 16, 2009
  27. git-push.txt: describe how to default to pushing only current branchChris Johnsen, Mar 15, 2009

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.