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
> fast-forward.

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.

Felipe Contreras
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

Reply via email to