On Tue, Sep 10, 2013 at 3:26 AM, Matthieu Moy <Matthieu.Moy@xxxxxxxxxxxxxxx> wrote: > Felipe Contreras <felipe.contreras@xxxxxxxxx> 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. 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'. >> 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? Because as you said, they don't know what that is. >> '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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html