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