Felipe Contreras <felipe.contre...@gmail.com> 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")
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html