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