I think Linus is right that the semantics of "git commit" and "git add" are not broken and do not need fixing. But Carl and others are right that they are not self-explanatory to most people, whether or not they have been tainted by CVS and its ilk. Maybe this is a job for a little contextual documentation (aka hand-holding) to accompany the tutorial and reference docs. How about we add a set of "expert" flags in the config, gating access to non-intuitive behavior and to idioms that should be discouraged in casual use. For instance, with an empty config, "git commit -m" fails with a message to the effect of: "As a general rule, you shouldn't use the -m flag unless you're scripting git for automation purposes. If this is what you are doing, or if you insist on committing without feedback about the state of your tree, you need to set the 'expert-commit-message' flag". Likewise, when your working copy does not match HEAD, "git commit" with neither -a nor an explicit list of files fails, saying: "'git commit' on a dirty working copy does the Right Thing! But some people find the Right Thing counter-intuitive at first. Either stick to 'git commit -a' or read the docs and set the 'expert-commit-dirty' flag." And "git add" still does the right thing, but warns: "Remember, git is not CVS. 'git add' has taken a snapshot of the current _contents_ of the newly added files, not just their names.
From now on, you will need to 'git mark' edits to them if you want
them to be part of the next commit, just like edits to files that have already been committed. This warning can be suppressed by setting the 'expert-add-content' flag." Note that 'expert-commit', etc. should NOT change the semantics of any command that doesn't error out. They should just enable idioms that a novice user is likely to try and get unexpected results. They should be overridable from the environment, of course, either one by one (export GIT_EXPERT_COMMIT_MESSAGE=y) or wholesale (export GIT_I_GROK_IN_FULLNESS_UP_TO=1.4.4). Cheers, - Michael - 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