"git commit -a" Doesn't Add New Files. Why?

The documentation clearly says that running "git commit -a" doesn't add new files to the index. I wonder why that choice was made.

Would the addition of "git commit -A" (note the capital letter) that works the same as "git commit -a", except that new files are also added be something you'd consider?

Cordially, Jon Forrest

On Tue, May 27, 2025 at 09:03:55AM -0700, Jon Forrest wrote:

I use `git commit -a` all the time in workspaces that are dirty. It would be exceedingly annoying if `git commit -a` were to act like `git add . && git commit`.

[Not being part of the team I can't answer this. But as a user I wouldn't mind, and I would almost never use it.]

Nico

Nico Williams <nico@cryptonector.com> writes:

True, but not quite. You would want your "git add ." to be safe in dirty working trees---at least some folks wanted so badly enough that "git add ." pays attention to the ".gitignore" mechanism.

But `git commit -a` would not change, even if it won't add cruft with well curated .gitignore files. That will be a terrible backward incompatible change for those who expect it only deals with the files it knows about (including the one that is not yet tracked but its presence is known via "git add -N").

On 5/28/25 3:24 PM, Junio C Hamano wrote:

Just to make it clear - I was only discussing adding a '-A' (capital A) option to git commit. Its current behavior with '-a' (small a) wouldn't change.

Jon

On Tue, May 27, 2025, at 18:03, Jon Forrest wrote:

I think it makes sense to only include tracked files. But (in any case) when the option was added[1][2] it meant:

    git-diff-files --name-only | xargs git-update-cache
    git commit

And this `git diff-files --name-only` prints tracked files which are changed.

Given that you apparently had to pipe filenames to a command that updates the cache (obsolete for: index[2]) and then do a commit I will assume that mistakes were more costly. What if you piped in all changed tracked files and untracked files? And you forgot to ignore your build artifacts? That’s more things you have to undo.

Also note the commit message.  It doesn’t sound like an endorsement.

I have also not seen anyone really recommend using this option.

† 1: f0b32737ad5 (Add "git commit --all" since everybody seems to want
    it., 2005-07-19)
† 2: And the documentation that you saw was added in cb95bf488b4
    (Documentation: git-commit -a, 2006-01-13)
† 3: index: also known as staging area

"Kristoffer Haugsbakk" <kristofferhaugsbakk@fastmail.com> writes:

But .gitignore is your friend these days.

Given that a precursor of modern "gitignore" did not appear until fee88256 (ls-files: rework exclude patterns., 2005-07-28), and "git status" started to pay attention only at ba966b95 (Teach git-status-script about git-ls-files --others, 2005-08-26), it is understandable that nobody was enthused about grabbing any new files out of the working tree back then.

And unless you are total newbie, you would know that you create a new file far far less often than you modify an existing file, so you would be more careful about avoiding to include new and unwanted files than forgetting to add new and necessary files.

"Kristoffer Haugsbakk" <kristofferhaugsbakk@fastmail.com> writes:

You mean "git commit -a"?

I actually do to anybody who is the kind of person who concentrates on a single thing and completes that single thing well before moving to another task. It is a perfect tool for the job for such a way of working.

Like when doing "git merge" or "git pull". There, the "single thing" that the person concentrates on is to complete the merge, and with a reasonably written pre-commit hook to make sure there is no leftover conflict markers [*], "git commit -a" to conclude a conflicted merge is fairly safe.

[Footnote]

 * There should actually be pre-add hook to make it even less
   annoying.  After you see conflicts, "git add -u" happily adds the
   contents of the files in the working tree, with conflict markers
   still in them.  You can rely on the pre-commit hook that is
   triggered when you run "git commit" next time, and then use "git
   checkout -m" to recreate the conflicted higher-stage index
   entries for these paths, but if we had pre-add hook, we shouldn't
   have to know how to recover from such a mistake in the first
   place.