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

From: Felipe Contreras <felipe.contreras@gmail.com>
Date: Sep 8, 2013, 02:52 UTC
Message-ID: <CAMP44s3Vaqe-POwQb30AGdarf=ObdPUay3QEMqxHV3NKiPAouA@mail.gmail.com>
In-Reply-To: <20130904092527.GB22348@sigill.intra.peff.net>

On Wed, Sep 4, 2013 at 4:25 AM, Jeff King <peff@peff.net> wrote:

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

How? Subversion would complain if you have local changes when you do 'svn pull', there's no notion of remotes, branches and merges are rare, and forget about rebases.

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

These integrators should know what they are doing, so they can do 'git pull --merge', or better 'git config pull.mode merge', as Linus himself suggested (or something like that).

The defaults should care most about the clueless users.

-- 
Felipe Contreras