From: Junio C Hamano <gitster@pobox.com>
Date: Thu, 24 Feb 2011 17:27:29 GMT
Subject: Re: Why doesn't git commit -a track new files
Message-ID: <7v7hcp2vi6.fsf@alter.siamese.dyndns.org>
In-Reply-To: <20110224112246.3f811ac2@glyph>

Marco <netuse@lavabit.com> writes:

> I'm new to git and a bit confused about how some commands work.
>
> git add .                    -- Adds everything *but* deleted files
> git add -A                   -- Adds everything
> git commit -a -m "whatever"  -- Commits everything *but* new files
>
> I don't understand why there's not switch (is there?) for commit to commit new
> and deleted files, like -A for git add?

Historical accident.  In the early days of git, there was no .gitignore
mechanism, so a mode that operates on everything under the working tree
was almost always an undesired thing to have (think *.o files).

Then .gitignore mechanism came, and "add ." has become usable.  But
"commit -a" has been widely used way before that.

If you look at "commit -a" within that context, you would understand why
it should only look at the paths git knows about.

Of course, "add -A" is a much later invention.  The option was named "-A"
with capital letter, even though there is no "add -a".

This was because I knew we would eventually want to have "commit -A" that
grabs everything and new files (honoring the gitignore mechanism), and
aimed for consistency between "add -A" that I was adding, and "commit -A"
that was yet to be written.  See 3ba1f11 (git-add --all: add all files,
2008-07-19).

I think it now is sensible to add "commit -A" if somebody is inclined to
do so.  Nobody felt the need for it strongly enough to do so, it seems.