Thread (25 messages) flat view 25 messages, 4 authors, 2016-06-15

Re: Re: Pull is Evil

From: Felipe Contreras <hidden>
Date: 2016-06-15 23:00:58

W. Trevor King wrote:
On Thu, May 01, 2014 at 02:16:50PM -0500, Felipe Contreras wrote:
quoted
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.
quoted
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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help