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

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

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

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

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.

quoted

quoted

quoted

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.

In this part of the email you are quoting I was not intending to say
anything about clueless users at all, nor even about what defaults there
are. John indicated that he could not imagine a scenario of "git pull
$remote", so I gave an example.

-Peff