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

From: Jeff King <peff@peff.net>
To: Felipe Contreras <felipe.contreras@gmail.com>
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: Sun, 8 Sep 2013 00:18:05 -0400	[thread overview]
Message-ID: <20130908041805.GB14019@sigill.intra.peff.net> (raw)
In-Reply-To: <CAMP44s3Vaqe-POwQb30AGdarf=ObdPUay3QEMqxHV3NKiPAouA@mail.gmail.com>

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

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.

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