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

Junio C Hamano [off-list ref] 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/

On Fri, Jun 28, 2013 at 12:16:53AM +0200, Matthieu Moy wrote:

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.

I admit that I'd be happy with a config option that just disabled pull
entirely (forcing people to fetch/merge explicitly) to avoid this type
of beginner mistake.  With an unconfigured pull.rebase, this patch
does that for merge/rebase cases, while still letting folks pull when
it's a clean fast forward (usually ok).

I'd also be happy with an opt-in disable.  The real solution would be
to talk my group out of using a central shared repository or into
using pull-free feature branches, but I don't see either on my
horizon.  Git doesn't need to change to mitigate sloppy-shared-repo
problems, but having some sort of anti-pull configuration option would
certainly help me out.

Cheers,
Trevor

-- 
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy