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

From: Matthieu Moy <matthieu.moy@grenoble-inp.fr>
Date: Jun 27, 2013, 22:16 UTC
Message-ID: <vpqwqpf9p2i.fsf@anie.imag.fr>
In-Reply-To: <7v4ncjs5az.fsf_-_@alter.siamese.dyndns.org>

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

Show 6 quoted lines

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