Junio C Hamano wrote:
> If we step back a bit, because we are forcing him to differentiate
> these two pulls in his mental model anyway, perhaps it may help
> people (both new and old) if we had a new command to make the
> distinction stand out more. What if the command sequence were like
> this instead?
> $ git checkout maint
> $ git update [ origin maint ]
> $ git pull [--no-ff] developer-remote topic-branch
> $ git push [ origin maint ]
> where the new command 'update' enforces the '--ff-only' update. And
> then we would stop telling "'git pull' first" when a push does not
In addition to barf when it's not a fast-forward, such command can
switch the parents, so it appears 'maint' was merged to 'origin/maint'.
Many people have complained about this order.
> Stepping back even further, and thinking what is different between
> these two pulls, we notice that the first one is pulling from the
> place we push back to. Perhaps a way to solve this issue, without
> having to introduce a new 'git update' and updating the tutorials,
> may be disallow fetch+merge by default only when pulling from the
> place the result is going to be pushed back to?
Which is basically essentially the same as not specifying anything, or
rather, running `git pull` without arguments.
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html