Re: push.default: current vs upstream

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Jeff King <peff@xxxxxxxx> writes:

> On Mon, Apr 02, 2012 at 09:40:22AM +0200, Matthieu Moy wrote:
>> For the others, they already have to learn about the "upstream"
>> semantics. And making argumentless "git pull" and "git push" purposely
>> asymetric to make it simple for the user sounds like an oxymoron to me.
> We can make the operations technically symmetric in terms of the actual
> sources and destinations from which commits are moved, but they are not
> necessarily symmetric in the user's workflow.

It seems rather natural to me to have "asymetric workflow, asymetric
commands" by default. So, if one wants to push to a place other than
upstream, say "git push public-repo branch", or set your upstream to
where you want to push (simple with "git push -u"), and say explicitely
"git pull repo branch".

I can hardly imagine someone knowing what "git pull" does, and
_surprised_ to see that "git push" sends commits to the same place. I
agree that sending commits to upstream may be a mistake, but I don't
think it can happen "by surprise".

There are also ways to shoot yourself in the foot with when setting
upstream to something other that where you usually push. For example,
run "git rebase -i" without argument, and it will offer you to rewrite
some published history. "git pull --rebase" also becomes a potentially
dangerous operation, while it's normally harmless with

And I still have my concern with real beginners: what advice would you
give to a user whose "git push" is denied because of non-fast forward. I
raised this concern already:

and I essentially had the answer "telling the user to pull is wrong"
(with which I disagree), but no one managed to give another advice.

With real-real-newbies, this is my number 1 issue (they don't even do
branches, they just run push, git tells them to pull, and they come to
me saying "git is broken, we can't work"). With not-so-newbies, I have
less experience ;-).

>> The discussion seems to focuse on 'let's make "git push" easy to
>> explain', but I think the right thing to do is to make _Git_ easy to
>> explain. With "push.default = current", we'll have a hard time
>> explaining how "git pull" works.
> Do we have a hard time explaining how "git pull" works now?

I don't think so, but Junio's argument is that explaining what push
would do with 'upstream' would be too complex, and that 'current' is
easier to explain. If 'git pull' is simple, then 'git -c
push.current=upstream push' is equally simple.

Matthieu Moy
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at

[Newbies FAQ]     [Linux Kernel Development]     [Free Online Dating]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Free Online Dating]     [Photo]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]     [Linux Resources]

Add to Google