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 'push.default=upstream'. 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: http://thread.gmane.org/gmane.comp.version-control.git/192547/focus=193196 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 http://www-verimag.imag.fr/~moy/ -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html