W. Trevor King wrote:
> On Fri, May 02, 2014 at 02:13:25PM -0500, Felipe Contreras wrote:
> > It would matter almost exactly zero.
>
> Some folks have explicit merge policies, and deciding how much that
> matters is probably best left up to the projects themselves and not
> decided in Git code.
Let's make some fake numbers to see around how much this would matter.
The amount of people that are not used to Git could be around 60%.
Of these, the amount that would be doing integration is probably 30%, as
those tasks would be relegated to more advanced users. A project that
lets non-advanced users to integration probably wouldn't care if the
merges are fast-forward or not, but let's say 10% of them do. That makes
3%.
On the other hand, user might do merges when trying to bring their local
repositories up-to-date, let's say 100% of them do. Of those, the ones
in a project that doesn't want fast-forward merges is probably 10%. That
makes 10%. However, such projects wouldn't want them merging
'origin/master' to 'master', but 'topic' to 'master', so they shouldn't
be using `git pull` anyway, but for the sake of argument let's say that
they do.
That would make around 8%, and 6% of those wouldn't be using `git pull`
anyway.
So no, for all intents and purposes it doesn't matter. I would rather
concentrate on the issue more than 90% of the users face.
> > And just as they can do pull.promot = true, they can do pull.mode =
> > fetch-only.
>
> Why would you run a fetch-only pull instead of running 'git fetch'? I
> think it would make more sense to have 'pull.mode = none' with which
> 'git pull …' turns into a no-op suggesting an explicit
> fetch/{merge|rebase}. Having something like that available would
> help with the training issue that pull.prompt was addressing.
I fail to see how training them to do this:
% git config --global pull.mode none
% git pull
% git fetch
% git merge --no-ff
Is preferable than training them to do:
% git pull --no-ff
--
Felipe Contreras--
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