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

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