Jeff King <peff@xxxxxxxx> writes: > On Thu, Apr 05, 2012 at 06:46:51PM +0200, Matthieu Moy wrote: > >> 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". > > That makes sense _if_ the user is thinking about pull and push as > symmetric commands. That may be immediately obvious for some people's > mental models. But I suspect it is not for others (it is not for mine, > though I obviously do not count as a beginner). 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. > 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. > 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". > I'm less concerned with explaining and more concerned about safe > defaults. Yes, my rant about simplicity was a reply to Junio, who was arguing about simplicity: Junio C Hamano writes: | Obviously the former ["current"] is much simpler to explain and understand, as | people do not have to learn upstream tracking before doing their first | "push". Your arguments about safety are valid (we don't agree on the relative importance), but I think the argument of simplicity simply doesn't hold. 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. -- 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