W. Trevor King wrote:
> On Thu, May 01, 2014 at 02:16:50PM -0500, Felipe Contreras wrote:
> > The only problem would be when it's not desirable, however, that's a
> > problem of the user's ignorance, and the failure of the project's
> > policity to communicate clearly to him that he should be running
> > `git merge --no-ff`. There's absolutely nothing we can do to help him.
> I think “user ignorange” is the *only* problem with git pull.
That, and the fact that 'git pull' does something wrong by default.
> > The only thing we could do is not allow fast-forward merges either, in
> > which case `git pull` becomes a no-op that can't possibly do anything
> > ever.
> My interest in all of the proposed git-pull-training-wheel patches is
> that they give users a way to set a finger-breaking configuration that
> makes pull a no-op (or slows it down, like 'rm -i …'). Then folks who
> compulsively run 'git pull' (e.g. because SVN habits die slowly) can
> set an option that gives them something to think about before going
> ahead and running the pull anyway. The space in 'git pull' makes a
> $ alias 'git pull'='echo "try fetch/merge!"'
> solution unfeasible, and clobbering /usr/libexec/git-core/git-pull
> seems a bit extreme.
What is wrong with 'git pull' doing a merge when it can be fast-forward?
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