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

From: Felipe Contreras <felipe.contreras@gmail.com>
To: Jeff King <peff@peff.net>
Cc: John Keeping <john@keeping.me.uk>,
	Junio C Hamano <gitster@pobox.com>,
	git@vger.kernel.org, Andreas Krey <a.krey@gmx.de>
Subject: Re: [PATCH 0/3] Reject non-ff pulls by default
Date: Sat, 7 Sep 2013 23:37:13 -0500	[thread overview]
Message-ID: <CAMP44s01LL2JCKzqa0Qc5MfBz9zfMXR4H8jZdauLOi-D0JVHpw@mail.gmail.com> (raw)
In-Reply-To: <20130908041805.GB14019@sigill.intra.peff.net>

On Sat, Sep 7, 2013 at 11:18 PM, Jeff King <peff@peff.net> wrote:
> On Sat, Sep 07, 2013 at 09:52:16PM -0500, Felipe Contreras wrote:
>
>> 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.
>
> By "svn-like", I mean the people whose workflow is:
>
>   $ hack hack hack
>   $ git commit
>   $ git push ;# oops, somebody else pushed in the meantime
>   $ git pull
>   $ git push

But that's not svn-like at all.

> without using branches or worrying about the shape of history. I do not
> know what you mean by "svn pull", since that command does not exist
> (unless you are talking about svk?). In subversion, that workflow would
> be:
>
>   $ hack hack hack
>   $ svn commit ;# oops, somebody else committed in the meantime
>   $ svn update
>   $ svn commit
>
> Those people would now have to learn enough to choose between merge and
> rebase when running the "git pull".

But that's only if they don't care about the shape of history. In my
experience the people that cling more to centralized VCS do not like
merges, so they rebase everything to make it a straight line. That is
much more "svn-like".

So chances are they are already doing 'git pull --rebase' (or
similar), so their workflow wouldn't be affected.

> It may be OK to say "we do not care about that case, and it is a good
> thing that they learn enough to make the choice consciously." But I do
> think they exist.

Yeah, I'm sure they exist, but they are a tiny minority compared to
the amount of people who don't actually understand what 'git pull' is
doing and do merges by mistake.

-- 
Felipe Contreras