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.  Once
you understand the ff flags, you can set them however you like, and
pull will do what you tell it to.

> 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.

Cheers,
Trevor

-- 
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy