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

[Jeff King <peff@peff.net>]

On Sun, Sep 08, 2013 at 03:50:46AM -0400, Jeff King wrote:

> > > If you are interested, I can ask the opinion of some of the GitHub
> > > trainers. They see a lot of new users and have a sense of what kinds of
> > > confusion come up most frequently, what kinds of workflows they tend to
> > > see, etc. Their experience may be biased towards corporate-ish users,
> > > though, because those are the people who pay for training.
> > 
> > Ask. I'm sure they will tell you doing merges by mistake with 'git
> > pull' is an issue.
> 
> I've sent an email. I'll post the response when I get it.

Here is what I sent them (I am leaving both my mail and theirs unedited
to avoid any "telephone"-like confusion in trying to summarize):

        Right now, running "git pull" will always create a merge, unless
        the user has specifically configured it to perform a rebase.
        Some people find this problematic, because the project may care
        about the order of merges (e.g., so that --first-parent
        traversals do the right thing), and some users may accidentally
        do "backwards" merges from a main branch into a topic (either
        because they are clueless, or because they simply forgot).

        There is a proposal being considered to have "git pull" do
        nothing by default, but instead ask the user to specify whether
        to merge or rebase (with the option of setting a config value if
        you want it to do one by default).

        One concern I have is that new users may run across this
        relatively early. For example, the first time they "git push"
        and get a non-fast-forward because somebody else has already
        pushed, git suggests to run "git pull". At which point they will
        have to decide whether to merge or rebase. So what I'd like your
        opinions on is:

          1. Do new users have trouble with the concept of rebase vs
             merge?  How would they handle this change of behavior?

          2. Do new users have trouble with rebases in general? There
             are some complications over doing a normal merge, but I
             don't know how often they trip people up in practice.

And the responses I got were:

        1. New users definitely have trouble distinguishing between
        rebase and merge. Even people who have been using Git for a
        while on a basic level are sometimes confused by this.

        2. Most people we teach—even the ones who have been using Git
        for a while—don't know what a rebase is at all. They've heard of
        it, but they don't get it. It takes careful explanation to get
        the concept across and explain why it is not the same thing as a
        merge.

        Speaking for myself, about half of the time in the Foundations
        class I'll explain `pull --rebase` and `branch.autosetuprebase`.
        (Whether we get to it depends on class interest and ability.)
        When we do address that topic, we always recommend that
        rebase-on-pull is the right thing to do, since the merges Git
        creates are just noise that makes history hard to work with in
        the ways you have pointed out. (For smart classes, I like to
        make the analogy of Git to a distributed database, and point out
        how the merge on pull is just Git's mechanism for resolving
        split-brain writes. I explain that those merges aren't a
        deficiency in Git; they're just what has to happen by default.
        The fact that Git handles split-brain writes so well by itself
        is amazing.)

        My input would be to continue to have `pull` merge by default.
        Those merges aren't great, but new users won't have any idea how
        to make a decision about them at that point. As it is, it just
        works, and it works quite elegantly. Once you start to learn
        some things, you can tune Git up to work even more elegantly by
        rebasing, but having to understand that concept and make a
        decision on your first (or second or third or twentieth) pull is
        probably asking too much.

and:

        Just a few more elements to add:

        * I have been teaching rebase and what it means in _some_ of my
        Git Foundations classes as of late.  But "some" means there are
        a majority that do not get it.

        * These are the people that get "formal" training on Git.  What
        about all the newbies?  They really won't have a foundation for
        what these two "flavors" mean.

        * The merge is very different from what Subversion presents as a
        default.  That's a possible point in the "option's favor."

        * In the end though, the "simplest thing that works" should be
        the default without a choice.  To me, a choice implies knowledge
        of the benefits of each option.  I would say that the majority
        of our Git students do not, at the beginning of Git usage,
        understand the difference.

I did not specifically ask in the original about whether backwards
merges were a problem, though I think that is touched on in the
responses.

If you'd like me to ask something specifically, I can relay the
question, or I can ask them to come join the discussion here.

-Peff