Hi,

On Thu, 30 Nov 2006, Raimund Bauer wrote:

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