John Keeping <john@xxxxxxxxxxxxx> writes: > I think there are two distinct uses for pull, which boil down to: > > (1) git pull > (2) git pull $remote $branch > > For (1) a merge is almost always the wrong thing to do since it will be > backwards and break --first-parent. > > But for (2) a merge is almost always the correct thing to do (in fact it > may even be correct to create a merge commit even when this fast > forwards) because this most likely comes for a pull request workflow. Peff already covered (1)---it is highly doubtful that a merge is "almost always wrong". In fact, if that _were_ the case, we should simply be defaulting to rebase, not failing the command and asking between merge and rebase like jc/pull-training-wheel topic did. We simply do not know what the user wants, as it heavily depends on the project, so we ask the user to choose one (and stick to it). I am not sure about (2), either. Is it really "almost always the correct thing to do"? I tend to think myself that (2) is a lot more likely to prefer merging than (1) would, but I certainly wouldn't say "almost always". Again if "almost always" were the case, wouldn't it make sense for that mode of invocation of the command to even defeat "pull.rebase" configuration and default to merge, unless explicitly told to "pull --rebase" from the command line? (the last question is rhetoric, if anybody is wondering). -- 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