On Mon, Sep 9, 2013 at 3:17 PM, Jeff King <peff@xxxxxxxx> wrote: > 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. Wall these concerns can be tackled with an error message that says: "The pull was not fast-forward, please either merge or rebase. If unsure, run 'git pull --merge'." -- Felipe Contreras -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html