Re: [PATCH 0/3] Reject non-ff pulls by default

Felipe Contreras [off-list ref] writes:

The problem is the newcomers, and the newcomers will most definitely
not activate a configuration option to tell them that they are doing
something potentially undesirable.

I teach Git to 200 newcommers each year. All of them run "git pull" the
first day, but believe me, very few of them want to know what a rebase
is at that time.

(I also work with experienced computer scientists, and actually, very
few of them want to know what a rebase is either :-( )

By the time they learn about pull.mode, they probably already know
what a rebase is. So what is the point of the configuration in the
first place?

[...]

That doesn't mean anything, you are assuming the user will do 'git
pull --rebase', and there's no rationale as to why they would end up
doing that.

So, you insist in asking the user to chose between rebase and merge, but
you also insist that they will not chose rebase? So, why ask?

'git commit' by default "prevents" users from creating commits without
first adding changes to the staging area, and since it's a concept
unique to Git, it's fair to say that none of the newcomers understand
why 'git commit' is failing, the error messages is not particularly
useful either.

I don't particularly agree that not defaulting to --all was a good idea,
but that's another topic.

But the error message is rather clear:

  no changes added to commit (use "git add" and/or "git commit -a")

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