git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: John Tapsell <johnflux@gmail.com>
To: Junio C Hamano <gitster@pobox.com>
Cc: Git Mailing List <git@vger.kernel.org>
Subject: Re: git push
Date: Wed, 25 Feb 2009 09:08:36 +0000	[thread overview]
Message-ID: <43d8ce650902250108q48837d85mfcee33b990c5bf00@mail.gmail.com> (raw)
In-Reply-To: <7v4oyjc64z.fsf@gitster.siamese.dyndns.org>

2009/2/25 Junio C Hamano <gitster@pobox.com>:
> John Tapsell <johnflux@gmail.com> writes:
>
>> 2009/2/25 Junio C Hamano <gitster@pobox.com>:
>>
>>> Having an easy way to ask to push only one branch (typically the currently
>>> checked-out one) is a good thing.  You can obviously say "git push origin
>>> master" (or whatever branch you are on).  We also added "git push origin
>>> HEAD".  I thought we even added "git push HEAD" or "git push --current",
>>> but I may be mistaken.
>>>
>>> But if you are talking about changing the default when "git push" is run
>>> without any parameter, I have to say it is a terrible idea, for two
>>> reasons, and one is too obvious to state so I wouldn't repeat it and talk
>>> only about the other one.
>>
>> Presumably the obvious is that it might be confusing to existing
>> users?  Perhaps, but it doesn't cause any damage.  It's moving to a
>> 'safer' default.
>
> No, it is not merely confusing but is outright dangerous to people who
> expect the "matching refs" behaviour.  It is not safer at all.

I see your point - perhaps "git push" should push the current branch
if the branch name matches the remote name (so if the current 'git
push' would have pushed it).  Otherwise tell the user how to force it
to push.

> Please don't talk about changing the default without thinking the
> ramifications through.

Talking about doesn't harm anything.  I don't really get why you're a
bit hostile.


>>> I've noticed that people who ask for such a default tend to push too often
>>> and worse they tend to push before they have their act together.  Surely
>>> their other branches may not be ready, but it is likely their current
>>> branch isn't either ;-)
>>
>> You're against making push affect only the current branch in order to
>> punish people who push too often?  Okaaay..
>
> "Too often" is not a problem by itself per-se, but "still broken"
> certainly is, and "not thought through" also is to a certain degree.  You
> often see people commit and push out an early part of a series, and then
> later regret that they realize the approach in these initial segment does
> not pan out and another avenue was much better, but it is too late to take
> them back and rebase.
>
> And there unfortunately is a correlation between "too often" and the other
> two.  Not very strong correlation with "still broken", but moderately
> strong correlation with "not thought through".
>
> And this is not about punishing.  It is about getting into a different
> mindset.  Unlike CVS/SVN, committing and publishing can be made into
> different phases with git, and not pushing too early allows you produce a
> lot better results.  "I want to push only this branch" is often (not
> always, but "often" stands with strong correlation) a sign that other
> things are not ready, and by definition you couldn't have thought through
> interactions between what you _think_ is ready (i.e. the current branch)
> and the other ones that are not ready.  In other words, it is about
> encouraging people to think things through before publishing.

I'm a bit surprised that you always push all your branches at once.  I
often have several branches checked out at different stages of
development.  Perhaps working on a branch, then I find a serious bug,
so I switch to master and fix the bug there.  I have never wanted to
push multiple branches at once.

>>> If you shoot for the least damage for such people, the sanest default for
>>> "git push" would be to do nothing.  You *always* say what to push where,
>>> then there is no risk of pushing something you did not intend to.  Perhaps
>>> "push.default = never" configuration may not be such a bad idea?
>>
>> That wouldn't be a terrible idea, although perhaps a bit strange.
>
> I would say that is the sanest default, and I often wish people in the git
> training industry never teach "git push" without $remote and $refs
> parameter to new people until they understand what they are doing.
>
> You can add words other than 'never' to the repertoire, such as 'current',
> or 'matching'.  I think the configuration actually should be
> "remote.<name>.push", not "push.default", though.
>
> Oh, and the value 'current' can be spelled as 'HEAD' already there.

  parent reply	other threads:[~2009-02-25  9:10 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-02-25  6:38 git push John Tapsell
2009-02-25  6:46 ` Jeff King
2009-02-25  7:01 ` Junio C Hamano
2009-02-25  7:09   ` John Tapsell
2009-02-25  7:44     ` Junio C Hamano
2009-02-25  9:02       ` Jeff King
2009-02-25  9:26         ` Junio C Hamano
2009-02-25  9:51           ` Jeff King
2009-02-25  9:08       ` John Tapsell [this message]
2009-02-25  9:49         ` Junio C Hamano
2009-02-25 10:06           ` John Tapsell
2009-02-25  9:34       ` Jay Soffian
2009-02-25  9:51         ` Junio C Hamano
2009-02-25 22:58   ` Finn Arne Gangstad
2009-03-05  8:45     ` Andreas Ericsson
2009-03-05  8:56       ` John Tapsell
2009-03-05  9:44       ` Finn Arne Gangstad
     [not found] <CAJmx4Nxh_WzkO-S=SN9E=aODCrfs+QCig4sT+Q8eQ+Pv1hB2+w@mail.gmail.com>
2012-03-19 16:24 ` Kevin O'Brien

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=43d8ce650902250108q48837d85mfcee33b990c5bf00@mail.gmail.com \
    --to=johnflux@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    /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).