From: "Junio C Hamano" <gitster@xxxxxxxxx>
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).
We only offer a limited list. It won't be sufficient for all use cases.
It wasn't for me.
The ability to say 'stop' if it doen't match expectations, as
the --no-ff option would give, would be a help, as the user can then
decide what to do (read the manual or `google` the problem perhaps ;-).
the option of having a hook (if suggested), while suitable for advanced
users won't help those that need that help, rather a few simple safe
options are needed.
I generally support the ability to set an option to reject non-ff pulls.
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).
--
Philip
--
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