Re: [PATCH] pull: require choice between rebase/merge on non-fast-forward pull

[Matthieu Moy <Matthieu.Moy@grenoble-inp.fr>]

Junio C Hamano <gitster@pobox.com> writes:

> Because letting a trivial merge automatically handled by Git is so
> easy with "git pull", a person who is new to Git may not realize
> that the project s/he is interacting with may prefer "rebase"
> workflow.  Add a safety valve to fail "git pull" that is not a
> fast-forward until/unless the user expressed her preference between
> the two.

IMHO, that would be terrible for beginners.

My experience with many beginners/students is: they run "git pull" to
get changes from their co-workers, don't read the messages. When there's
no conflict, it's OK, Git creates the merge commit and they continue
working. When there are conflicts, they fix it (or not), and forget to
commit, continue working, and commit when they really need to, later.
That's bad: mixing merges with actual changes is terrible. But that
works. And that's a very common mistake in my experience :-(.

Now, give the same user as above "git pull --rebase". rebase may stop
because of conflicts, the user may fix it, but then if the user
continues working, he's on a detached HEAD with a rebase ongoing. Some
of the changes went away, they may come back one day if the user runs
"git rebase --continue".

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/