Re: Please default to 'commit -a' when no changes were added

Goswin von Brederlow [off-list ref] writes:

For SVN users it gets much worse:

vi existing-file.c # do some changes
vi new-file.c      # create the file
git add new-file.c
vi new-file.c      # do some more changes
git commit

A SVN user would expect the current working copies of existing-file.c
and new-file.c to be commited. Instead only new-file.c is commited and
only the fist modification.

While this case is still highly confusing to non git users I do see that
it can't be easily changed. And my suggestion doesn't change it. The
call to "git add" creates an index so the commit would only act on the
index.

But then, you'd still have the confusion for people expecting the SVN
semantics. They'd use "git commit-without-dash-a" happily untill they
have to add a new file, and the day the do a "git add" on a new file,
commit doesn't add their changes to existing files, and ... WTF!?

Don't get me wrong: I do agree that not everybody have a use for the
index. Typically, I teach Git to students, who are light-years away
from understanding what "clean commit, small and related changes"
means. They have no use for the index, they just use Git as a way to
share code, and possibly as a backup mechanism. I just teach them
"always use the -a option of 'git commit' for now, you'll learn about
the power of 'git commit-without-dash-a' later". Unless when they
forget to say "-a", it just works. And it even works when they add new
files, when they resolve conflicts after a merge, ... which your
proposal does not solve.

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/