Matthieu Moy <Matthieu.Moy@xxxxxxxxxxxxxxx> writes:
> There's a rule of thumb which works very well for beginners: when "git
> push" tells you to pull before, then pull before. This rule of thumb
> works, but only provided "push" and "pull" are symmetrical.
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.
Obviously "push and pull are symmetrical" holds true for that single
branch workflow, but that does not mean a more complex workflow must
be symmetrical.
Even though I think 'upstream' will be a superset of what 'current'
wants to do in an ideal world where the user configures everything
right (hence it ought to be the better default between the two), I
do not think that the target audience "let's change the default"
folks are trying to help is those who set @{upstream} correctly
point the destination for a branch they want to push to and leave it
unset for a strictly private branch. If we choose the default that
would primarily make it efficient for people who can configure
everything right, we are missing the point of this discussion. I
think the target audience to be helped is the people who do not
(yet) do anything complex, and the point of this discussion is to
help them avoid getting surprised.
And by "surprised", I do not necessarily mean "dangerous". While we
should aim to avoid "dangerous", we should avoid "ununderstandable"
even more.
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.
On the other hand, the user needs to know not just 'branch' but also
understand the concept of @{upstream} in order to use 'upstream'
without surprise. When something goes wrong, prerequisite knowledge
that is required to understand it is greater. Also the current
implementation of 'upstream' has some weird semantics (or undesigned
bugs) pointed out by Peff, which would make it even more confusing.
That makes me suspect that 'current' might be a more appropriate
default between the two. From that simple default, those in the
"shared central repository" world can graduate to 'upstream' once
they know what an 'upstream' is and how to take advantage of
per-branch configuration. Similarly, those in the "publish to be
pulled" world would graduate to 'matching'.
--
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