Re: Re: Pull is Evil

[Felipe Contreras <felipe.contreras@gmail.com>]

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
> shell-side:
> 
>   $ 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?

-- 
Felipe Contreras