From: Andreas Ericsson <ae@op5.se>
To: Junio C Hamano <gitster@pobox.com>
Cc: demerphq <demerphq@gmail.com>,
Andrew Sayers <andrew-git@pileofstuff.org>,
git@vger.kernel.org
Subject: Re: Please discuss: what "git push" should do when you do not say what to push?
Date: Tue, 20 Mar 2012 11:00:57 +0100 [thread overview]
Message-ID: <4F685559.8040402@op5.se> (raw)
In-Reply-To: <7v1uoo9pyo.fsf@alter.siamese.dyndns.org>
I just realized I've had the proposed behaviour for "upstream" backwards
all along. I thought "upstream" was meant to do what "matching" does
today.
I'd like to change my vote to "upstream" instead, although I think the
name for it is truly horrible. Perhaps that's just me though, since
we're using "upstream" as a remotename for repositories we get from
afar but work on internally as well.
On 03/19/2012 11:38 PM, Junio C Hamano wrote:
> demerphq<demerphq@gmail.com> writes:
>
>> ... I thought the worse case here is
>> minor inconvenience, not data loss or anything else that is obviously
>> harmful.
>
> If your definition of harm is limited to data loss then we wouldn't be
> talking about updating the default from matching to current or upstream.
> "If your push failed, pushed what you did not mean to, or did not push
> what you meant to, you would correct the mistake" applies equally to a new
> person who expected "current" (or "upstream") and got "matching", or an old
> person who expected "matching" and got "current".
>
> The purpose of the default change is to reduce surprises to people who
> haven't yet learned Git too well. And for them,
>
> I was on master, I said 'git push' without saying what to push to
> where, and it resulted in master updated at the central repository.
>
> is the least surprising outcome. Note that a learnt Git user would not
> express what he did this way; he will say 'I was on *my* master' and
> 'the master at the central repository was updated with *my* master', but
> the change of the default is to help those who haven't even learned that
> your branches and branches at the central server are not always connected.
>
> Choice of "upstream" is more convenient for users who learned Git a bit
> more and knows the distinction between branches you have and branches the
> central server has. For them, "I was on my 'topic' branch, that was
> forked from the 'master' branch at the central repository. I said 'git
> push', and I updated the 'master' over there with my 'topic'", is also not
> surprising, but it is more advanced audience than those helped by the
> default setting to push 'current'.
>
> In either way, once people learn sufficiently to the point that they can
> choose their own default that suit them, there is no need for handholding.
> They won't be surprised.
>
> But except for one case you should *not* forget about.
>
> The ones who get pulled the old default under their feet while not paying
> too much attention to this discussion. The change will hit them with a
> surprise, and that is what I am trying to avoid here.
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
Considering the successes of the wars on alcohol, poverty, drugs and
terror, I think we should give some serious thought to declaring war
on peace.
next prev parent reply other threads:[~2012-03-20 10:01 UTC|newest]
Thread overview: 44+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-03-17 5:10 Please discuss: what "git push" should do when you do not say what to push? Junio C Hamano
2012-03-17 5:22 ` Junio C Hamano
2012-03-17 10:05 ` Andrew Sayers
2012-03-18 18:50 ` Junio C Hamano
2012-03-18 21:26 ` Ævar Arnfjörð Bjarmason
2012-03-19 0:29 ` Junio C Hamano
2012-03-19 7:29 ` Sebastien Douche
2012-03-19 20:11 ` Andrew Sayers
2012-03-19 21:43 ` Junio C Hamano
2012-03-19 22:20 ` demerphq
2012-03-19 22:38 ` Junio C Hamano
2012-03-20 10:00 ` Andreas Ericsson [this message]
2012-03-19 22:47 ` Andrew Sayers
2012-03-19 22:59 ` Junio C Hamano
2012-03-20 21:20 ` Andrew Sayers
2012-03-20 23:09 ` Junio C Hamano
2012-03-20 23:41 ` Andrew Sayers
2012-03-21 0:25 ` Junio C Hamano
2012-03-20 14:12 ` Martin Langhoff
2012-03-20 15:28 ` Junio C Hamano
2012-03-20 18:31 ` Martin Langhoff
2012-03-20 16:43 ` Jakub Narebski
2012-03-21 17:54 ` Summary of discussion on "git push" default change Junio C Hamano
2012-03-21 18:05 ` Matthieu Moy
2012-03-17 14:00 ` Please discuss: what "git push" should do when you do not say what to push? Joey Hess
2012-03-19 0:36 ` Junio C Hamano
2012-03-17 18:43 ` fREW Schmidt
2012-03-18 4:02 ` H. Peter Anvin
2012-03-18 5:43 ` Marcus D. Hanwell
2012-03-18 16:52 ` Sebastian Schuberth
2012-03-19 9:07 ` Peter Krefting
2012-03-19 9:35 ` Letting remote repositories override local configuration Jonathan Nieder
2012-03-19 12:21 ` Peter Krefting
2012-03-19 18:57 ` Please discuss: what "git push" should do when you do not say what to push? Kevin Ballard
2012-03-20 2:27 ` Antony Male
2012-03-20 12:04 ` Jakub Narebski
2012-03-20 13:04 ` Antony Male
2012-03-20 7:13 ` Nathan Gray
2012-03-20 12:00 ` Ben Tebulin
2012-03-20 12:00 ` Ben Tebulin
2012-03-20 12:00 ` Ben Tebulin
2012-03-20 12:01 ` Ben Tebulin
2012-03-20 12:36 ` Filipe Fernandes
-- strict thread matches above, loose matches on Subject: below --
2012-03-19 18:26 Michael K. Johnson
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=4F685559.8040402@op5.se \
--to=ae@op5.se \
--cc=andrew-git@pileofstuff.org \
--cc=demerphq@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.