On Fri, May 02, 2014 at 02:11:05PM -0500, Felipe Contreras wrote: > 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. I realize this has veered off into talking about an "update" command, and not necessarily "pull", but since there a lot of proposals floating around, I wanted to make one point: if we are going to do such a switch, let's please make it something the user explicitly turns on. One common workflow for GitHub users is to back-merge master into a topic, because they want the final "integrated" version on the topic branch. That lets it get review, run tests, and even get test-deployed from there before merging to master (and then when it does merge to master, we know the result will be a trivial merge). This workflow helps spread out the load (there is no central "integration" person or script, and the merge itself becomes a possible part of the review/test cycle). Some projects will do this by rebasing the topic, but that has its own complications (like making collaboration harder because the commits are being frequently rewritten). Such users are going to run "git pull origin master" or just "git pull" to get that merge. A switch to disallowing non-ff is going to disrupt that workflow. I think we can live with that, as they should be able to stop and say "no, my workflow wants these merges", set a config variable, and be done. But I think that is the same moment they should probably be deciding on whether their workflow wants "regular" or "reverse" merges. And I do not think the decision between the two has an obvious split over which is better. So it makes sense to me to take the opportunity when the user is thinking about their workflow to have them specify one or the other. -Peff -- 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