Re: [git] Re: Pull is Evil

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]