Junio C Hamano <gitster@xxxxxxxxx> writes: > I actually think the "pull before push again" was written with only > CVS style non-branching workflow in mind, in other words, only to > help somebody who works on his master against the central master. It doesn't have much to do with branching/non-branching. You may use branches, and still work collaboratively on them. There was an example above in the same thread: http://thread.gmane.org/gmane.comp.version-control.git/192547/focus=192694 There are also cases like "I pushed from my laptop and I'm back to my desktop", or "the content has been edited from GitHub's web interface". Actually, I hardly see a case where "pull before push again" (with or without --rebase or such) is wrong for a beginner. > Pushing 'current' from a branch 'topic' forked from either 'master' > or 'origin/master' will create a new branch 'topic' at the central > repository. But that is straightforward and understandable. The user > will see what happened in the feedback from the command, and there > is no need for the user to be experienced enough to know the mapping > of @{upstream} to understand why it happened. "I am on 'topic' and > I pushed, I created 'topic' there". Very simple explanation exists. Very simple explanation exist for what "push" does, but not for "the global picture of what push and pull do". And really, the case "Git prevents me from pushing, I don't know what to do" is a problem for people who don't get the whole remote/branch/upstream/... things. Actually, I'm starting to wonder if the whole "upstream" thing should not be deactivated by default, and replaced with a simpler mechanism like "pull.default", similar to what "push.default" does today. Then, users could set "pull.default=current", and "git pull" would pull a branch with the same name remotely. Or users could set "pull.default=upstream" and get what Git does today. But that's a much larger change, then ... -- 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