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
Attachment:
signature.asc
Description: OpenPGP digital signature