Carl Worth wrote: > If git's model imposes the requirement, "we should first teach one > thing, then move on to teach a subsequent thing", it would be just > that much nicer if the commands themselves could help us do that, > (because the default would do the thing they would need first, and > then the user has to explicitly do _something_ else to get the > subsequent thing). > > See? I'm just trying to make the command set more naturally provide > the same flow of learning that we've been proposing for the tutorial. Not exactly. For example more user-friendly is "mv -i" than "mv", but noone proposes to make "mv -i" default (well, you can alias "mv" to "mv -i" in shell, while you cannot alias "commit" to "commit -a" in git). So i think having the default geared towards advanced users and not newbie users is O.K. By the way, I find it a bit annoying that "git commit" outputs git-status output (possibly multi-line if you have many untracked but unignored files in working area) before "nothing to commit". P.S. Is there a difference between "git commit ." and "git commit -a"? -- Jakub Narebski Warsaw, Poland ShadeHawk on #git - 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