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

On Tue, Sep 10, 2013 at 3:26 AM, Matthieu Moy
[off-list ref] wrote:

Felipe Contreras [off-list ref] writes:

quoted

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.

And who says they have to? This is a straw man argument.

May of them don't want to know what the staging area is, that's why
they run 'git commit --all', and just like that they can run 'git pull
--merge'.

quoted

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?

[...]

quoted

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?

Because as you said, they don't know what that is.

quoted

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

It the same topic, the project already made a choice, and precisely
because of the same reasoning that 'git commit --all' is required,
'git pull --merge' should be required.

But the error message is rather clear:

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

And we can do the same:

"Read more with 'git pull --help' or do 'git pull --merge'."

-- 
Felipe Contreras