git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: John Tapsell <johnflux@gmail.com>
Cc: Peter Krefting <peter@softwolves.pp.se>, git@vger.kernel.org
Subject: Re: Not pushing all branches?
Date: Fri, 13 Mar 2009 13:02:26 -0700	[thread overview]
Message-ID: <7v4oxxgpil.fsf@gitster.siamese.dyndns.org> (raw)
In-Reply-To: <43d8ce650903130125m6335d189obbcdb86ec9036083@mail.gmail.com> (John Tapsell's message of "Fri, 13 Mar 2009 08:25:05 +0000")

John Tapsell <johnflux@gmail.com> writes:

> 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).

  parent reply	other threads:[~2009-03-13 20:04 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-03-13  7:48 Not pushing all branches? Peter Krefting
2009-03-13  8:12 ` Imran M Yousuf
2009-03-13  9:44   ` Peter Krefting
2009-03-13 10:49     ` Johannes Schindelin
2009-03-13 11:38     ` Finn Arne Gangstad
2009-03-13  8:25 ` John Tapsell
2009-03-13 10:51   ` Johannes Schindelin
2009-03-13 12:37     ` John Tapsell
2009-03-13 13:53       ` Johannes Schindelin
2009-03-13 13:56         ` John Tapsell
2009-03-13 15:48           ` Michael J Gruber
2009-03-13 16:00           ` Johannes Schindelin
2009-03-13 20:02   ` Junio C Hamano [this message]
2009-03-14  1:08     ` Miles Bader
2009-03-17  8:24       ` Jeff King
2009-03-13 16:49 ` Jeff King
2009-03-14  1:27   ` [PATCH] git-push.txt: describe how to default to pushing only current branch Chris Johnsen
2009-03-14 19:26     ` Junio C Hamano
2009-03-14 20:34       ` Jeff King
2009-03-14 20:56         ` Jeff King
2009-03-15  2:49           ` Chris Johnsen
2009-03-15 11:30             ` [PATCH] git-push.txt: describe how to default to pushing only Chris Johnsen
2009-03-17  7:46             ` [PATCH] git-push.txt: describe how to default to pushing only current branch Jeff King
2009-03-14 21:25         ` Junio C Hamano
2009-03-14 21:46           ` Jeff King
2009-03-16  4:51             ` Junio C Hamano
2009-03-15  2:32       ` [PATCH v2] " Chris Johnsen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=7v4oxxgpil.fsf@gitster.siamese.dyndns.org \
    --to=gitster@pobox.com \
    --cc=git@vger.kernel.org \
    --cc=johnflux@gmail.com \
    --cc=peter@softwolves.pp.se \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).