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

[John Keeping <john@keeping.me.uk>]

On Wed, Sep 04, 2013 at 05:25:27AM -0400, Jeff King wrote:
> On Wed, Sep 04, 2013 at 09:10:47AM +0100, John Keeping wrote:
> 
> > 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'm one of the people who argues that it should rebase there ;-)  The
point of jc/pull-training-wheel is to help users think about that.

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

The scenario I have is a central repository where some developers use a
topic branch workflow but others are less familiar with Git and don't
really think about what they're doing.

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

OK - so I was missing this.  Given this, the jc/pull-training-wheel
series is doing the right thing here.