# "git commit -a" Doesn't Add New Files. Why? 7 messages from 2025-05-27 to 2025-05-28. Participants: Jon Forrest, Nico Williams, Kristoffer Haugsbakk, Junio C Hamano. Thread: https://gitlist.dev/t/63532 ## Jon Forrest, 2025-05-27 16:03 Subject: "git commit -a" Doesn't Add New Files. Why? Message-ID: <1014npb$rbl$1@ciao.gmane.io> URL: https://gitlist.dev/e/1014npb%24rbl%241%40ciao.gmane.io ``` 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 ``` ## Nico Williams, 2025-05-27 16:31 Subject: Re: "git commit -a" Doesn't Add New Files. Why? Message-ID: URL: https://gitlist.dev/e/aDXo0Enj4cQzKQkK%40ubby In-Reply-To: <1014npb$rbl$1@ciao.gmane.io> ``` 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 -- ``` ## Kristoffer Haugsbakk, 2025-05-27 16:43 Subject: Re: "git commit -a" Doesn't Add New Files. Why? Message-ID: <09518eac-948e-46be-9cd2-64304e78af81@app.fastmail.com> URL: https://gitlist.dev/e/09518eac-948e-46be-9cd2-64304e78af81%40app.fastmail.com In-Reply-To: <1014npb$rbl$1@ciao.gmane.io> ``` 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 ``` ## Junio C Hamano, 2025-05-28 21:16 Subject: Re: "git commit -a" Doesn't Add New Files. Why? Message-ID: URL: https://gitlist.dev/e/xmqqzfewqvvw.fsf%40gitster.g In-Reply-To: <09518eac-948e-46be-9cd2-64304e78af81@app.fastmail.com> ``` "Kristoffer Haugsbakk" 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. ``` ## Junio C Hamano, 2025-05-28 22:24 Subject: Re: "git commit -a" Doesn't Add New Files. Why? Message-ID: URL: https://gitlist.dev/e/xmqqjz60pe65.fsf%40gitster.g In-Reply-To: ``` Nico Williams 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"). ``` ## Jon Forrest, 2025-05-28 23:06 Subject: Re: "git commit -a" Doesn't Add New Files. Why? Message-ID: <550e4935-6ae6-44d8-bde2-d61db3656830@gmail.com> URL: https://gitlist.dev/e/550e4935-6ae6-44d8-bde2-d61db3656830%40gmail.com In-Reply-To: ``` 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 ``` ## Junio C Hamano, 2025-05-28 23:34 Subject: Re: "git commit -a" Doesn't Add New Files. Why? Message-ID: URL: https://gitlist.dev/e/xmqq8qmgpaxh.fsf%40gitster.g In-Reply-To: <09518eac-948e-46be-9cd2-64304e78af81@app.fastmail.com> ``` "Kristoffer Haugsbakk" 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. ```