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

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

[Jon Forrest]

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

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

[Nico Williams]

On Tue, May 27, 2025 at 09:03:55AM -0700, Jon Forrest wrote:
> The documentation clearly says that running "git commit -a"
> doesn't add new files to the index. I wonder why that choice
> was made.

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`.

> 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?

[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
-- 

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

[Junio C Hamano]

Nico Williams <nico@cryptonector.com> writes:

> On Tue, May 27, 2025 at 09:03:55AM -0700, Jon Forrest wrote:
>> The documentation clearly says that running "git commit -a"
>> doesn't add new files to the index. I wonder why that choice
>> was made.
>
> 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`.

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").

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

[Jon Forrest]

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

> 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").


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

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

[Kristoffer Haugsbakk]

On Tue, May 27, 2025, at 18:03, Jon Forrest wrote:
> The documentation clearly says that running "git commit -a"
> doesn't add new files to the index. I wonder why that choice
> was made.

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

>
> 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?

-- 
Kristoffer Haugsbakk

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

[Junio C Hamano]

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

> 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.

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.

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

[Junio C Hamano]

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

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

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.