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

From: Jeff King <peff@peff.net>
Date: Sep 8, 2013, 05:21 UTC
Message-ID: <20130908052107.GA15610@sigill.intra.peff.net>
In-Reply-To: <CAMP44s3kow9dooPzK6iD8p2LAgt1mtFuaNsVhkJHrqe4D+8xLQ@mail.gmail.com>

On Sun, Sep 08, 2013 at 12:09:34AM -0500, Felipe Contreras wrote:

Show 7 quoted lines

> > It's not if you understand the difference between merge-then-commit and
> > commit-then-merge. But for a clueless user who has been told "replace
> > svn commit" with "git commit && git push" and replace "svn update" with
> > "git pull", it is quite similar.
> 
> Well, yeah, but if they are so clueless they have to be told what to
> do, they can be told to do 'git pull --merge' instead, no?

I think it's fine to tell them to do "git pull --merge". What I'd worry more about is somebody who is suddenly presented with the choice between "--rebase" and "--merge" and doesn't know which to choose. We've created a cognitive load on the user, and even more load if they choose --rebase and don't quite understand what it means.

The current warning message in jc/pull-training-wheel is quite neutral between the two options. Perhaps we should lean more towards merging?

I guess that works against John's case, though, which is clueless people working on a project that _does_ care about the shape of history. At least they would have to stop and think for a moment, though, which might help (and maybe convince them to ask more clueful project members). I don't know.

-Peff