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

On Sat, Sep 7, 2013 at 11:18 PM, Jeff King [off-list ref] wrote:

On Sat, Sep 07, 2013 at 09:52:16PM -0500, Felipe Contreras wrote:

quoted

On Wed, Sep 4, 2013 at 4:25 AM, Jeff King [off-list ref] wrote:

quoted

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