On Fri, Apr 06, 2012 at 09:44:48AM +0200, Matthieu Moy wrote: > I think exactly the opposite. Once you learnt about remote-tracking > branches, about "git fetch" Vs "git pull", you understand why "git pull" > and "git push" are not strictly speaking symmetrical operations. > > But just from the wording, it should be obvious that the commands are > doing something somehow symmetrical. My mind may be warped from too much git and I may be misremembering my early days, but I feel like I never considered "push" and "pull" to be symmetric opposites. I dunno. We are both talking about some hypothetical population of new users, and I'm not sure either of us has hard data. > > So shouldn't the advice for a non-fast-forward push be: > > > > if $source_ref is currently checked out > > advise "git checkout $source_ref, and then..." > > fi > > if $dest_remote == branch.$source_ref.remote && > > $dest_ref == branch.$source_ref.merge > > advise "git pull" > > else > > advise "git pull $dest_remote $dest_ref" > > fi > > > > That handles only one ref, of course. If you get multiple non-ff > > failures, I'm not sure what we should advise. > > The topic ct/advise-push-default does essentially that indeed. I think it does the first half (recommend checkout if it was a non-HEAD). But the "pull before push" message just says: Updates were rejected because the tip of your current branch is behind its remote counterpart. Merge the remote changes (e.g. 'git pull') before pushing again. which is not exactly right. Saying "e.g." lets clueful people know that the details of merging might be different, but I doubt that subtlety is helpful for new users. > > You wrote above that we'll have a hard time explaining how "git pull" > > works. But I don't think so; if it hasn't been a problem with > > "matching", then why would it with "current"? > > I mis-spoke. I think I meant something like "if the assumption that > explaining push -c push.current=upstream is hard, then we'll have a hard > time explaining git pull". That makes more sense to me. > About safety, I don't think we can tell in general which bad push is the > most serious. push.default=current may create branches unexpectedly, > while push.default=upstream would ask you to "push --set-upstream" when > creating the remote branch. push.default=upstream may push to the master > when you wanted to create a remote topic branch. My feeling is that both > are equally bad, but maybe I'm wrong here. I would say without hesitation that fast-forwarding the upstream is more likely to be disastrous than creating a new branch. However, push.default=current can also fast-forward an existing branch (although if you have a local "foo" and its upstream is _not_ the remote "foo", I find it extremely unlikely that a remote "foo" also exists). On the other hand, one thing we have not talked about is how one gets into the "topic push fast-forwards master" situation. Which is running: $ git checkout -b topic origin/master I'm not sure if that is something totally clueless people will run. And maybe by the time people are intermediate enough git users to run that, they will have figured out how upstream works. So maybe my concern is overblown. I consider the much more likely scenarios for a new user to be: $ git clone ... && cd project $ hack hack hack $ git push which will work with either "current" or "upstream", or: $ git clone ... && cd project $ git checkout foo ;# equivalent of "git checkout -b foo origin/foo" $ hack hack hack $ git push which also works with both, or: $ git clone ... && cd project $ git checkout -b topic $ hack hack hack $ git push which will error out for "upstream", and create a new branch "topic" on the remote with "current". -Peff -- 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