Re: Why doesn't git commit -a track new files

From: Miles Bader <miles@gnu.org>
Date: Feb 25, 2011, 04:30 UTC
Message-ID: <buozkpk91nf.fsf@dhlpc061.dev.necel.com>
In-Reply-To: <4D6672F7.4020101@drmicha.warpmail.net>

Michael J Gruber <git@drmicha.warpmail.net> writes:

Show 10 quoted lines

>> git add -A && git commit -m "Message"
>
> "commit -a" is much like "add -u", at least when used without file
> arguments ("pathspec").
>
> "commit -A" does not exist, so that "git add -A && git commit" is your
> only way.
>
> Why does it not exist? Because you should at least
> "git add -A && git status && behappy && git commit".

The exact same argument applies to "git commit -a" of course, but it's still supported. Why? Because it's a nice convenience for many common situations. It isn't the least bit unsafe if one does git status _first_.

> Also, "-A" supports a very "un-gitty" way of using git. This makes it
> unlikely that someone cares to implement it... (By "un-gitty" I don't
> mean a matter of personal taste, but a matter of fruitful habits.)

Nonsense.

The index is a great idea, and cool and useful in many situations; I use it heavily, and wish other systems had something like it. But there's nothing "un-gitty" or "unfruitful" about directly commiting sometimes.

For the record, I usually use the index, but sometimes when the changes are simple, I'll use shortcuts like "commit -a", because they're handy. Typically I'll do "git status" _first_, check that everything's kosher, and then do "git commit -a ...". If "git commit -A" existed, I'd use that in the same way.

-Miles

-- 
Mayonnaise, n. One of the sauces that serve the French in place of a state
religion.