Re: Pull is Evil

From: W. Trevor King <wking@tremily.us>
Date: May 2, 2014, 19:46 UTC
Message-ID: <20140502194637.GL28634@odin.tremily.us>
In-Reply-To: <5363ee55ac2af_70ef0f30cf3@nysa.notmuch>

On Fri, May 02, 2014 at 02:13:25PM -0500, Felipe Contreras wrote:

Show 27 quoted lines

> W. Trevor King wrote [1]:
> > On Fri, May 02, 2014 at 01:55:36PM -0500, Felipe Contreras wrote:
> > > W. Trevor King wrote:
> > > > On Thu, May 01, 2014 at 08:14:29PM -0500, Felipe Contreras wrote:
> > > > > W. Trevor King wrote:
> > > > > > My proposed --prompt behavior is for folks who think “I often run
> > > > > > this command without thinking it through all the way.  I'm also
> > > > > > not used to reading Git's output and using 'reset --hard' with the
> > > > > > reflog to reverse changes.  Instead of trusting me to only say
> > > > > > what I mean or leaving me to recover from mistakes, please tell me
> > > > > > what's about to change and let me opt out if I've changed my
> > > > > > mind.”
> > > > > 
> > > > > Unfortunately those folks by definition wouldn't know about the
> > > > > --prompt option.
> > > > 
> > > > But once such folks are identified, you just have to convince them
> > > > (once) to set the pull.prompt config.  That's a lot easier than
> > > > convincing them (for every pull) to set the appropriate ff flag.
> > > 
> > > It wouldn't matter if by the default non-fast-forward merges are
> > > rejected.
> > 
> > It would matter if you [only wanted] them making non-fast-forward
> > merges (e.g. for explicitly-merged topic branches).
> 
> It would matter almost exactly zero.

Some folks have explicit merge policies, and deciding how much that matters is probably best left up to the projects themselves and not decided in Git code. I like having a place to explain why a feature is useful and has been included in projects I maintain.

> And just as they can do pull.promot = true, they can do pull.mode =
> fetch-only.

Why would you run a fetch-only pull instead of running 'git fetch'? I think it would make more sense to have 'pull.mode = none' with which 'git pull …' turns into a no-op suggesting an explicit fetch/{merge|rebase}. Having something like that available would help with the training issue that pull.prompt was addressing.

Cheers, Trevor

[1]: With David Kastrup's "only wanted" typo fix.

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