On Thu, Apr 5, 2012 at 8:46 PM, Matthieu Moy
[off-list ref] wrote:
I can hardly imagine someone knowing what "git pull" does, and
_surprised_ to see that "git push" sends commits to the same place.
It seems you assume that people use in a _centralized_ workflow.
In this case, 'upstream' does largely the right thing, so no one
will be surprised.
However, many of those who got used to a distributed workflow will find
that surprising, because when they created a new branch that meant it
to push as a _new_ branch. So other people could take a look, or they
may need the maintainer ACK to push anything to 'master'. Also they may
have a policy nothing should be fast-forwarded to master, but only to
be merged with a merge commit.
And then it is more natural for people to think in terms of names that
are immediately obvious to anyone, while 'upstream' behavior depends on
the state that is not immediately obvious. You may start a new topic
branch based on 'master' or some the latest release to have a more
stable base. And 'upstream' will work differently in this case. If you
know about 'tracking' then it may be obvious to you, but it is not so
obvious to those who only start to use git for short time...
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:
Don't use a central workflow, because it sucks :)
Seriously, why do you care about beginners who use a centralized workflow
and not beginners who have to use with existing projects that use more or
less distributed workflow, where pushing to 'master' is more likely to be
the wrong thing to do than otherwise... And when push is denied, they may
ask someone whether they are doing something wrong. In case when master
is fast-forwarded silently, they are not likely to notice that they did
something wrong, and the fact that happens only sometimes (depending on
some "tracking" feature which they have not heard) is not very helpful.
Dmitry