{"thread":{"id":"63532","subject":"\"git commit -a\" Doesn't Add New Files. Why?","startedAt":"2025-05-27T16:09:12Z","lastAt":"2025-05-28T23:34:05Z","messageCount":7,"participants":["Jon Forrest","Nico Williams","Kristoffer Haugsbakk","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"519000","messageId":"1014npb$rbl$1@ciao.gmane.io","threadId":"63532","inReplyTo":null,"subject":"\"git commit -a\" Doesn't Add New Files. Why?","fromName":"Jon Forrest","fromEmail":"nobozo@gmail.com","sentAt":"2025-05-27T16:03:55Z","receivedAt":"2025-05-27T16:09:12Z","isPatch":false,"sender":{"key":"nobozo@gmail.com","avatar":"https://gravatar.com/avatar/37c6a7b57f29b3f35c6a9016537907c52f15bbf98575617dc046bcec6bf06372?d=mp&s=160"},"body":"The documentation clearly says that running \"git commit -a\"\ndoesn't add new files to the index. I wonder why that choice\nwas made.\n\nWould the addition of \"git commit -A\" (note the capital letter)\nthat works the same as \"git commit -a\", except that new files\nare also added be something you'd consider?\n\nCordially,\nJon Forrest\n\n\n"},{"id":"519003","messageId":"aDXo0Enj4cQzKQkK@ubby","threadId":"63532","inReplyTo":"1014npb$rbl$1@ciao.gmane.io","subject":"Re: \"git commit -a\" Doesn't Add New Files. Why?","fromName":"Nico Williams","fromEmail":"nico@cryptonector.com","sentAt":"2025-05-27T16:31:12Z","receivedAt":"2025-05-27T16:38:21Z","isPatch":false,"sender":{"key":"nico@cryptonector.com","avatar":null},"body":"On Tue, May 27, 2025 at 09:03:55AM -0700, Jon Forrest wrote:\n> The documentation clearly says that running \"git commit -a\"\n> doesn't add new files to the index. I wonder why that choice\n> was made.\n\nI use `git commit -a` all the time in workspaces that are dirty. It\nwould be exceedingly annoying if `git commit -a` were to act like `git\nadd . && git commit`.\n\n> Would the addition of \"git commit -A\" (note the capital letter)\n> that works the same as \"git commit -a\", except that new files\n> are also added be something you'd consider?\n\n[Not being part of the team I can't answer this. But as a user I\nwouldn't mind, and I would almost never use it.]\n\nNico\n-- \n"},{"id":"519005","messageId":"09518eac-948e-46be-9cd2-64304e78af81@app.fastmail.com","threadId":"63532","inReplyTo":"1014npb$rbl$1@ciao.gmane.io","subject":"Re: \"git commit -a\" Doesn't Add New Files. Why?","fromName":"Kristoffer Haugsbakk","fromEmail":"kristofferhaugsbakk@fastmail.com","sentAt":"2025-05-27T16:43:10Z","receivedAt":"2025-05-27T16:43:36Z","isPatch":false,"sender":{"key":"kristofferhaugsbakk@fastmail.com","avatar":null},"body":"On Tue, May 27, 2025, at 18:03, Jon Forrest wrote:\n> The documentation clearly says that running \"git commit -a\"\n> doesn't add new files to the index. I wonder why that choice\n> was made.\n\nI think it makes sense to only include tracked files. But (in any case)\nwhen the option was added[1][2] it meant:\n\n git-diff-files --name-only | xargs git-update-cache\n git commit\n\nAnd this `git diff-files --name-only` prints tracked files which\nare changed.\n\nGiven that you apparently had to pipe filenames to a command that\nupdates the cache (obsolete for: index[2]) and then do a commit I will\nassume that mistakes were more costly. What if you piped in all changed\ntracked files and untracked files? And you forgot to ignore your build\nartifacts? That’s more things you have to undo.\n\nAlso note the commit message. It doesn’t sound like an endorsement.\n\nI have also not seen anyone really recommend using this option.\n\n† 1: f0b32737ad5 (Add \"git commit --all\" since everybody seems to want\n it., 2005-07-19)\n† 2: And the documentation that you saw was added in cb95bf488b4\n (Documentation: git-commit -a, 2006-01-13)\n† 3: index: also known as staging area\n\n>\n> Would the addition of \"git commit -A\" (note the capital letter)\n> that works the same as \"git commit -a\", except that new files\n> are also added be something you'd consider?\n\n-- \nKristoffer Haugsbakk\n\n"},{"id":"519101","messageId":"xmqqzfewqvvw.fsf@gitster.g","threadId":"63532","inReplyTo":"09518eac-948e-46be-9cd2-64304e78af81@app.fastmail.com","subject":"Re: \"git commit -a\" Doesn't Add New Files. Why?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2025-05-28T21:16:03Z","receivedAt":"2025-05-28T21:16:06Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Kristoffer Haugsbakk\" writes:\n\n> I think it makes sense to only include tracked files. But (in any case)\n> when the option was added[1][2] it meant:\n>\n> git-diff-files --name-only | xargs git-update-cache\n> git commit\n>\n> And this `git diff-files --name-only` prints tracked files which\n> are changed.\n>\n> Given that you apparently had to pipe filenames to a command that\n> updates the cache (obsolete for: index[2]) and then do a commit I will\n> assume that mistakes were more costly. What if you piped in all changed\n> tracked files and untracked files? And you forgot to ignore your build\n> artifacts? That’s more things you have to undo.\n\nBut .gitignore is your friend these days.\n\nGiven that a precursor of modern \"gitignore\" did not appear until\nfee88256 (ls-files: rework exclude patterns., 2005-07-28), and \"git\nstatus\" started to pay attention only at ba966b95 (Teach\ngit-status-script about git-ls-files --others, 2005-08-26), it is\nunderstandable that nobody was enthused about grabbing any new files\nout of the working tree back then.\n\nAnd unless you are total newbie, you would know that you create a\nnew file far far less often than you modify an existing file, so you\nwould be more careful about avoiding to include new and unwanted\nfiles than forgetting to add new and necessary files.\n"},{"id":"519105","messageId":"xmqqjz60pe65.fsf@gitster.g","threadId":"63532","inReplyTo":"aDXo0Enj4cQzKQkK@ubby","subject":"Re: \"git commit -a\" Doesn't Add New Files. Why?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2025-05-28T22:24:02Z","receivedAt":"2025-05-28T22:24:05Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Nico Williams writes:\n\n> On Tue, May 27, 2025 at 09:03:55AM -0700, Jon Forrest wrote:\n>> The documentation clearly says that running \"git commit -a\"\n>> doesn't add new files to the index. I wonder why that choice\n>> was made.\n>\n> I use `git commit -a` all the time in workspaces that are dirty. It\n> would be exceedingly annoying if `git commit -a` were to act like `git\n> add . && git commit`.\n\nTrue, but not quite. You would want your \"git add .\" to be safe in\ndirty working trees---at least some folks wanted so badly enough\nthat \"git add .\" pays attention to the \".gitignore\" mechanism.\n\nBut `git commit -a` would not change, even if it won't add cruft\nwith well curated .gitignore files. That will be a terrible\nbackward incompatible change for those who expect it only deals with\nthe files it knows about (including the one that is not yet tracked\nbut its presence is known via \"git add -N\").\n\n\n"},{"id":"519112","messageId":"550e4935-6ae6-44d8-bde2-d61db3656830@gmail.com","threadId":"63532","inReplyTo":"xmqqjz60pe65.fsf@gitster.g","subject":"Re: \"git commit -a\" Doesn't Add New Files. Why?","fromName":"Jon Forrest","fromEmail":"nobozo@gmail.com","sentAt":"2025-05-28T23:06:19Z","receivedAt":"2025-05-28T23:06:21Z","isPatch":false,"sender":{"key":"nobozo@gmail.com","avatar":"https://gravatar.com/avatar/37c6a7b57f29b3f35c6a9016537907c52f15bbf98575617dc046bcec6bf06372?d=mp&s=160"},"body":"\n\nOn 5/28/25 3:24 PM, Junio C Hamano wrote:\n\n> But `git commit -a` would not change, even if it won't add cruft\n> with well curated .gitignore files. That will be a terrible\n> backward incompatible change for those who expect it only deals with\n> the files it knows about (including the one that is not yet tracked\n> but its presence is known via \"git add -N\").\n\n\nJust to make it clear - I was only discussing adding a '-A' (capital\nA) option to git commit. Its current behavior with '-a' (small a)\nwouldn't change.\n\nJon\n\n\n"},{"id":"519125","messageId":"xmqq8qmgpaxh.fsf@gitster.g","threadId":"63532","inReplyTo":"09518eac-948e-46be-9cd2-64304e78af81@app.fastmail.com","subject":"Re: \"git commit -a\" Doesn't Add New Files. Why?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2025-05-28T23:34:02Z","receivedAt":"2025-05-28T23:34:05Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Kristoffer Haugsbakk\" writes:\n\n> I have also not seen anyone really recommend using this option.\n\nYou mean \"git commit -a\"?\n\nI actually do to anybody who is the kind of person who concentrates\non a single thing and completes that single thing well before moving\nto another task. It is a perfect tool for the job for such a way of\nworking.\n\nLike when doing \"git merge\" or \"git pull\". There, the \"single\nthing\" that the person concentrates on is to complete the merge, and\nwith a reasonably written pre-commit hook to make sure there is no\nleftover conflict markers [*], \"git commit -a\" to conclude a\nconflicted merge is fairly safe.\n\n\n[Footnote]\n\n * There should actually be pre-add hook to make it even less\n annoying. After you see conflicts, \"git add -u\" happily adds the\n contents of the files in the working tree, with conflict markers\n still in them. You can rely on the pre-commit hook that is\n triggered when you run \"git commit\" next time, and then use \"git\n checkout -m\" to recreate the conflicted higher-stage index\n entries for these paths, but if we had pre-add hook, we shouldn't\n have to know how to recover from such a mistake in the first\n place.\n"}]}