Re: [PATCH 0/3] Reject non-ff pulls by default

From: Jeff King <peff@peff.net>
Date: Sep 4, 2013, 09:25 UTC
Message-ID: <20130904092527.GB22348@sigill.intra.peff.net>
In-Reply-To: <20130904081047.GB2582@serenity.lan>

On Wed, Sep 04, 2013 at 09:10:47AM +0100, John Keeping wrote:

Show 7 quoted lines

> I think there are two distinct uses for pull, which boil down to:
> 
>     (1) git pull
>     (2) git pull $remote $branch
> 
> For (1) a merge is almost always the wrong thing to do since it will be
> backwards and break --first-parent.

Is it always wrong? You are assuming a topic-branch workflow where --first-parent is actually meaningful. What about a centralized workflow where everyone works on "master"? The correct thing to do on a non-ff push in that case is "git pull && git push". Some people would argue that the pull should rebase there, but I think there are valid arguments either way. We can discuss in that direction if you want.

I can perhaps buy the argument that it is better to help people who are using a topic branch workflow (which we generally want to encourage) to avoid making backwards merges, and the cost is that people with sloppy workflows will have to do more work / configuration. But we should be clear that this is a tradeoff we are making.

The patch in jc/pull-training-wheel talks about annoying old timers, but I think you may also be annoying clueless new users who simply want an svn-like workflow without thinking too hard about it.

Show 5 quoted lines

> > I do not think we know what we want is to affect "git pull origin".
> 
> I consider "git pull $remote" to be an artifact of the way git-pull is
> implemented on top of git-fetch; perhaps I'm missing something but I
> can't see a scenario where this is useful.

Imagine a workflow where each topic is in its own repository instead of in its own branch inside a repository. Or where each developer has his or her own repository, but everybody just works on the master branch of their repository (or perhaps uses branches, but keeps master as a stable base). Alice is the integration manager; Bob tells her that he has work ready to integrate. She runs "git pull ~bob/project", which will merge Bob's HEAD.

This is not very different from the kernel workflow, where Linus may do a "git pull $remote" to fetch a sub-system maintainer's work, except that these days people typically mark the to-be-integrated work in a "for-linus" branch or tag. However, you can find many "Merge git://" entries even in recent kernel history.

I think this kind of pull would fall into the same situation as your (2) above.

-Peff