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") -- Matthieu Moy http://www-verimag.imag.fr/~moy/ -- 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
