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

From: Jeff King <peff@peff.net>
Date: Sep 8, 2013, 04:43 UTC
Message-ID: <20130908044329.GA15087@sigill.intra.peff.net>
In-Reply-To: <CAMP44s01LL2JCKzqa0Qc5MfBz9zfMXR4H8jZdauLOi-D0JVHpw@mail.gmail.com>

On Sat, Sep 07, 2013 at 11:37:13PM -0500, Felipe Contreras wrote:

Show 9 quoted lines

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

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.

Show 10 quoted lines

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

I think we are talking about two classes of users. People who truly don't care about the shape of history will also not care about using "git pull --rebase", because the only reason to use it is to impact the shape of history.

I agree there is also a set of people coming from the centralized vcs world who want to keep a linear history.

-Peff