Hi, On Thu, 30 Nov 2006, Raimund Bauer wrote: > * Carl Worth wrote, On 30.11.2006 01:05: > > Let's help people do exactly that by making the behavior of "git > > commit -a" be the default for "git commit". > > > Maybe we could do that _only_ if the index matches HEAD, and otherwise keep > current behavior? > So people who don't care about the index won't get tripped up, and when you do > have a dirty index, you get told about it? So many people spoke for it, it's time I crash the wedding. >From a usability viewpoint, it is a horrible convention. The user has to remember too much of the side effects to handle the commit operation. The function of the program would no longer be dependent on the command line arguments and your config, but _also_ on something as volatile as the index. You would literally end up asking "did I change the index?" _everytime_ before you commit. And remember, even a simple "git add" changes the index! (Why it does is brutally clear once you grasp the concept of the staging area.) Worse, doing a "git commit --amend" should _not_ automatically add "-a" _even_ if the index matches the HEAD, since it is quite possible that you had a typo in the message you want to fix up. And quite possibly other options would not want that either. But here's an idea: tell the user that she has to tell git-commit which files she wants committed. Yes! That's it. Just tell it the friggin' files. And if you are a lazy bum, and want to commit _all_ modified files, git has a nice shortcut for ya: "-a". Ciao, Dscho - 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