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