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
