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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html