Goswin von Brederlow <goswin-...@web.de> 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/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
