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 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".
You are asking the new user to make a logical inference about the
relationship between push and pull. That inference may seem obvious to
you, and it may even be obvious to a large portion of new users. But
keep in mind that we are not debating whether "upstream" is a reasonable
thing for git to have, but rather whether it is a good default. My
concern is that upstream as a default would have negligible benefit for
people who do make the inference, but be dangerous for the group who do
not. We don't know the size of the latter, but my feeling is that it is
non-trivial.
> 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.
Yes, although that is often what you want in such a setup (e.g., you are
rebasing on top of the upstream branch, but publishing your work in
progress). However, I do agree that it can potentially be dangerous.
Two helpful saving graces are:
1. The first thing you see upon "git rebase -i" is a giant list of the
commits from your upstream branch. It is usually quite obvious that
you are rebasing more than you want in this case, and you can abort
before doing anything.
2. Even if you do rebase, you have made a _local_ error. You are not
hurting anyone until you push, at which point you will get a
non-fast-forward error, and you have a chance to fix things before
disrupting other people.
> 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.
It _is_ wrong unless the destination branch is also the configured
upstream. Which yes, it probably is if push.default is "upstream".
Unless you actually specified a push destination, in which case it may
not be. Or if you were pushing something besides HEAD.
If the push destination was $remote:$branch, it seems the only correct
thing is to suggest "git pull $remote $branch" in the general case, and
possibly simplify that to "git pull" if $remote:$branch is the
configured upstream. And if the source was HEAD, of course; otherwise
you would need to checkout.
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 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.
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 agree that your symmetry explanation is reasonably simple for
explaining what "git push" will do for new users (though I also think
"current" is quite easy to explain). I'm less concerned with explaining
and more concerned about safe defaults.
-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