{"thread":{"id":"56795","subject":"Git not commiting anything if file created and \"git add\"ed in pre-commit hook is the only file in the staging area","startedAt":"2021-10-27T19:03:54Z","lastAt":"2021-11-02T13:13:57Z","messageCount":9,"participants":["Peter Hunkeler","brian m. carlson","Jeff King","Junio C Hamano","Johannes Sixt"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"439812","messageId":"0165d68f-79a7-d8b7-1bba-89a1449e87a7@gmx.net","threadId":"56795","inReplyTo":null,"subject":"Git not commiting anything if file created and \"git add\"ed in pre-commit hook is the only file in the staging area","fromName":"Peter Hunkeler","fromEmail":"phunsoft@gmx.net","sentAt":"2021-10-27T19:03:49Z","receivedAt":"2021-10-27T19:03:54Z","isPatch":false,"sender":{"key":"phunsoft@gmx.net","avatar":null},"body":"Hi,\nGit seems to behave inconsistently when creating and \"git add\"ing\ncontent (files) from within a pre-commit hook. It claims there is\n\"nothing to commit\", if the stating area was empty before the commit\ncommand. Otherwise, the new content becomes part of the commit. See\ndetails on how to reproduce and a log of the individual steps below.\n\nRegards\nPeter\n\n\n=== Amended Git bug report\n=============================================================================================\nThank you for filling out a Git bug report!\nPlease answer the following questions to help us understand your issue.\n\nWhat did you do before the bug happened? (Steps to reproduce your issue)\n\nI'm quite new to using git, so please bear with me should I mix up some\nterminology.\n\nI need some new file to be created at each commit. The new file must\nbecome part of the commit.\nI thought a git pre-commit hook would be the appropriate place. While\nthe file is created as desired,\ngit does *not* include this new file in the commit, when there is\nnothing else in the staging area. It\nreports the new file as being untracked, and says nothing added to\ncommit. A git status immediately\nthereafter does, however, show the new file in the staging area. If I\nrun another commit just now, another\nnew file is created as expected, but this time, git adds them both to\nthe commit. This can be reliably\nreproduced by repeating 'git commit -m \"empty\"', and every second time,\nthe commit is done.\n\nFurther testing shows that the newly created file *is* added to the\ncommit, *if* at least one other change\nwas registered to be commited (git add some time before the git commit).\n\nSame behaviour, if two files are created and added withing the\npre-commit hook. Both files are added to\nthe commit only every second time, or if some other change does exist in\nthe staging area before the commit\ncommand.\n\nThe git pre-commit hook looks like this (indented for readability, only):\n     #!/bin/bash\n     fn=\"folder1\\folder1_file3_$(date +%Y%m%d_%H%M%S).txt\"\n     echo \"some text\" > $fn\n     git add $fn\n\nNote: This testing was done on Windows 10, but initially, I detected\nthis on a server running Linux.\n\n\n\n\n\n\nWhat did you expect to happen? (Expected behavior)\n\nI expect the file created and added from within the git pre-commit hook\nto become part of the commit\nno matter whether there are or aren't any other changes in the staging\nare, i.e. added beforehand.\n\n\n\n\nWhat happened instead? (Actual behavior)\n\nFile created and 'git added' from within the pre-commit hook shell\nscript is *not* added to the current\ncommit, if there are no other changes in the staging area.\n\nThe behaviour is inconsistent. If it is allowed to do a \"git add\" from\nwithin a pre-commit hook (is it allowed?),\nthen file added must become part of the commit irrespective of whether\nor not there are other changes in the\nstaging area that have been there *before* the commit command was\nissued. Else git should reject the \"git add\"\n(and other commands) from within the pre-commit hook.\n\nWhat's different between what you expected and what actually happened?\n\nsee above,\n\n\n\n\n\n\nAnything else you want to add:\n\nI'm adding the log from a terminal session where I reproduce the\nbehaviour below, limited by a line\nof '=' signs. Individual commands are separated by a line of '-' signs\nwith a comment what the next step\nwill be.\n\n========================================================================================================\n\n\n--- content of directory before git init\n---------------------------------------\nPeter@MySystem MINGW64 /d/Temp/git-testing (master)\n$ ls -lR\n.:\ntotal 6\n-rw-r--r-- 1 Peter 197121 9 Oct 25 13:55 file1.txt\n-rw-r--r-- 1 Peter 197121 9 Oct 25 13:55 file2.txt\ndrwxr-xr-x 1 Peter 197121 0 Oct 25 14:19 folder1/\ndrwxr-xr-x 1 Peter 197121 0 Oct 25 14:16 git-hook-saved/\n\n./folder1:\ntotal 2\n-rw-r--r-- 1 Peter 197121 9 Oct 25 13:58 folder1_file1.txt\n-rw-r--r-- 1 Peter 197121 9 Oct 25 13:58 folder1_file2.txt\n\n./git-hook-saved:\ntotal 1\n-rwxr-xr-x 1 Peter 197121 111 Oct 25 14:21 pre-commit*\n\n\n--- git init\n-----------------------------------------------------------------\nPeter@MySystem MINGW64 /d/Temp/git-testing\n$ git init\nInitialized empty Git repository in D:/Temp/git-testing/.git/\n\n\n--- git initial status\n-------------------------------------------------------\nPeter@MySystem MINGW64 /d/Temp/git-testing (master)\n$ git status\nOn branch master\n\nNo commits yet\n\nUntracked files:\n   (use \"git add <file>...\" to include in what will be committed)\n         file1.txt\n         file2.txt\n         folder1/\n         git-hook-saved/\n\nnothing added to commit but untracked files present (use \"git add\" to track)\n\n\n--- adding all initial data to the staging area\n---------------------------------\nPeter@MySystem MINGW64 /d/Temp/git-testing (master)\n$ git add \"*\"\n\n\n--- commiting initial data\n------------------------------------------------------\nPeter@MySystem MINGW64 /d/Temp/git-testing (master)\n$ git commit -m \"initial commit\"\n[master (root-commit) 4daefe7] initial commit\n  5 files changed, 12 insertions(+)\n  create mode 100644 file1.txt\n  create mode 100644 file2.txt\n  create mode 100644 folder1/folder1_file1.txt\n  create mode 100644 folder1/folder1_file2.txt\n  create mode 100644 git-hook-saved/pre-commit\n\n\n--- Show status after initial commit\n-----------------------------------------\nPeter@MySystem MINGW64 /d/Temp/git-testing (master)\n$ git status\nOn branch master\nnothing to commit, working tree clean\n\n\n--- Install git pre-commit hook, then do an empty commit\n-------------------------\nPeter@MySystem MINGW64 /d/Temp/git-testing (master)\n$ git commit -m \"empty 1\"\nwarning: LF will be replaced by CRLF in\nfolder1/folder1_file3_20211025_142454.txt.\nThe file will have its original line endings in your working directory\nOn branch master\nUntracked files:\n   (use \"git add <file>...\" to include in what will be committed)\n         folder1/folder1_file3_20211025_142454.txt\n\nnothing added to commit but untracked files present (use \"git add\" to track)\n\n\n--- Show whats in the file system at this point in time\n-------------------------\nPeter@MySystem MINGW64 /d/Temp/git-testing (master)\n$ ls -lR\n.:\ntotal 6\n-rw-r--r-- 1 Peter 197121 9 Oct 25 13:55 file1.txt\n-rw-r--r-- 1 Peter 197121 9 Oct 25 13:55 file2.txt\ndrwxr-xr-x 1 Peter 197121 0 Oct 25 14:24 folder1/\ndrwxr-xr-x 1 Peter 197121 0 Oct 25 14:16 git-hook-saved/\n\n./folder1:\ntotal 3\n-rw-r--r-- 1 Peter 197121  9 Oct 25 13:58 folder1_file1.txt\n-rw-r--r-- 1 Peter 197121  9 Oct 25 13:58 folder1_file2.txt\n-rw-r--r-- 1 Peter 197121 10 Oct 25 14:24 folder1_file3_20211025_142454.txt\n\n./git-hook-saved:\ntotal 1\n-rwxr-xr-x 1 Peter 197121 111 Oct 25 14:21 pre-commit\n\n\n--- What is the status of git? The \"add\" from the hook did\nwork!------------------------\nPeter@MySystem MINGW64 /d/Temp/git-testing (master)\n$ git status\nOn branch master\nChanges to be committed:\n   (use \"git restore --staged <file>...\" to unstage)\n         new file:   folder1/folder1_file3_20211025_142454.txt\n\n\n--- Immediately do another (not really empty) git commit\n-------------------------------\nPeter@MySystem MINGW64 /d/Temp/git-testing (master)\n$ git commit -m \"empty 2\"\nwarning: LF will be replaced by CRLF in\nfolder1/folder1_file3_20211025_142554.txt.\nThe file will have its original line endings in your working directory\n[master e9809aa] empty 2\n  2 files changed, 2 insertions(+)\n  create mode 100644 folder1/folder1_file3_20211025_142454.txt\n  create mode 100644 folder1/folder1_file3_20211025_142554.txt\n\n\n--- Show whats in the file system at this point in time\n-------------------------\nPeter@MySystem MINGW64 /d/Temp/git-testing (master)\n$ ls -lR\n.:\ntotal 6\n-rw-r--r-- 1 Peter 197121 9 Oct 25 13:55 file1.txt\n-rw-r--r-- 1 Peter 197121 9 Oct 25 13:55 file2.txt\ndrwxr-xr-x 1 Peter 197121 0 Oct 25 14:25 folder1/\ndrwxr-xr-x 1 Peter 197121 0 Oct 25 14:16 git-hook-saved/\n\n./folder1:\ntotal 4\n-rw-r--r-- 1 Peter 197121  9 Oct 25 13:58 folder1_file1.txt\n-rw-r--r-- 1 Peter 197121  9 Oct 25 13:58 folder1_file2.txt\n-rw-r--r-- 1 Peter 197121 10 Oct 25 14:24 folder1_file3_20211025_142454.txt\n-rw-r--r-- 1 Peter 197121 10 Oct 25 14:25 folder1_file3_20211025_142554.txt\n\n./git-hook-saved:\ntotal 1\n-rwxr-xr-x 1 Peter 197121 111 Oct 25 14:21 pre-commit\n\n\n--- Once more, this time really an \"empty\" commit again.\n------------------------\nPeter@MySystem MINGW64 /d/Temp/git-testing (master)\n$ git commit -m \"empty 3\"\nwarning: LF will be replaced by CRLF in\nfolder1/folder1_file3_20211025_142645.txt.\nThe file will have its original line endings in your working directory\nOn branch master\nUntracked files:\n   (use \"git add <file>...\" to include in what will be committed)\n         folder1/folder1_file3_20211025_142645.txt\n\nnothing added to commit but untracked files present (use \"git add\" to track)\n\n\n--- Show the status, same behaviour again.\n---------------------------------------------\nPeter@MySystem MINGW64 /d/Temp/git-testing (master)\n$ git status\nOn branch master\nChanges to be committed:\n   (use \"git restore --staged <file>...\" to unstage)\n         new file:   folder1/folder1_file3_20211025_142645.txt\n\n\n--- Yet another commit immediately thereafter\n---------------------------------------\nPeter@MySystem MINGW64 /d/Temp/git-testing (master)\n$ git commit -m \"empty 4\"\nwarning: LF will be replaced by CRLF in\nfolder1/folder1_file3_20211025_142659.txt.\nThe file will have its original line endings in your working directory\n[master 032a58e] empty 4\n  2 files changed, 2 insertions(+)\n  create mode 100644 folder1/folder1_file3_20211025_142645.txt\n  create mode 100644 folder1/folder1_file3_20211025_142659.txt\n\n\n--- Status?\n---------------------------------------------------------------------\nPeter@MySystem MINGW64 /d/Temp/git-testing (master)\n$ git status\nOn branch master\nnothing to commit, working tree clean\n\n\n--- Content of filesystem\n---------------------------------------------------------\nPeter@MySystem MINGW64 /d/Temp/git-testing (master)\n$ ls -lR\n.:\ntotal 7\n-rw-r--r-- 1 Peter 197121  9 Oct 25 13:55 file1.txt\n-rw-r--r-- 1 Peter 197121  9 Oct 25 13:55 file2.txt\n-rw-r--r-- 1 Peter 197121 10 Oct 25 14:27 file3.txt\ndrwxr-xr-x 1 Peter 197121  0 Oct 25 14:28 folder1/\ndrwxr-xr-x 1 Peter 197121  0 Oct 25 14:16 git-hook-saved/\n\n./folder1:\ntotal 7\n-rw-r--r-- 1 Peter 197121  9 Oct 25 13:58 folder1_file1.txt\n-rw-r--r-- 1 Peter 197121  9 Oct 25 13:58 folder1_file2.txt\n-rw-r--r-- 1 Peter 197121 10 Oct 25 14:24 folder1_file3_20211025_142454.txt\n-rw-r--r-- 1 Peter 197121 10 Oct 25 14:25 folder1_file3_20211025_142554.txt\n-rw-r--r-- 1 Peter 197121 10 Oct 25 14:26 folder1_file3_20211025_142645.txt\n-rw-r--r-- 1 Peter 197121 10 Oct 25 14:26 folder1_file3_20211025_142659.txt\n-rw-r--r-- 1 Peter 197121 10 Oct 25 14:28 folder1_file3_20211025_142815.txt\n\n./git-hook-saved:\ntotal 1\n-rwxr-xr-x 1 Peter 197121 111 Oct 25 14:21 pre-commit\n\n\n--- Creating a new file outside of hook\n--------------------------------------------------\nPeter@MySystem MINGW64 /d/Temp/git-testing (master)\n$ echo \"some text\" > file3.txt\n\n\n--- Git status?\n------------------------------------------------------------------\nPeter@MySystem MINGW64 /d/Temp/git-testing (master)\n$ git status\nOn branch master\nUntracked files:\n   (use \"git add <file>...\" to include in what will be committed)\n         file3.txt\n\nnothing added to commit but untracked files present (use \"git add\" to track)\n\n\n--- Adding the new file to the staging area\n------------------------------------------\nPeter@MySystem MINGW64 /d/Temp/git-testing (master)\n$ git add *\nwarning: LF will be replaced by CRLF in file3.txt.\nThe file will have its original line endings in your working directory\n\n\n--- Status again\n----------------------------------------------------------------\nPeter@MySystem MINGW64 /d/Temp/git-testing (master)\n$ git status\nOn branch master\nChanges to be committed:\n   (use \"git restore --staged <file>...\" to unstage)\n         new file:   file3.txt\n\n\n--- Committing the new file (and the one created by the pre-commit hook)\n--------------\nPeter@MySystem MINGW64 /d/Temp/git-testing (master)\n$ git commit -m \"one new file present\"\nwarning: LF will be replaced by CRLF in\nfolder1/folder1_file3_20211025_142815.txt.\nThe file will have its original line endings in your working directory\n[master 4ea47ec] one new file present\n  2 files changed, 2 insertions(+)\n  create mode 100644 file3.txt\n  create mode 100644 folder1/folder1_file3_20211025_142815.txt\n\n\n--- Status?\n--------------------------------------------------------------------\nPeter@MySystem MINGW64 /d/Temp/git-testing (master)\n$ git status\nOn branch master\nnothing to commit, working tree clean\n\n\n\n========================================================================================================\n\n\n\n\n\n\n\n\nPlease review the rest of the bug report below.\nYou can delete any lines you don't wish to share.\n\n\n[System Info]\ngit version:\ngit version 2.32.0.windows.2\ncpu: x86_64\nbuilt from commit: 3d45ac813c4adf97fe3733c1f763ab6617d5add5\nsizeof-long: 4\nsizeof-size_t: 8\nshell-path: /bin/sh\nfeature: fsmonitor--daemon\nuname: Windows 10.0 19042\ncompiler info: gnuc: 10.3\nlibc info: no libc information available\n$SHELL (typically, interactive shell): C:\\Programme\nNon-UAC\\Git\\usr\\bin\\bash.exe\n\n\n[Enabled Hooks]\npre-commit\n\n"},{"id":"439841","messageId":"YXnNvyi62j5gcxQV@camp.crustytoothpaste.net","threadId":"56795","inReplyTo":"0165d68f-79a7-d8b7-1bba-89a1449e87a7@gmx.net","subject":"Re: Git not commiting anything if file created and \"git add\"ed in pre-commit hook is the only file in the staging area","fromName":"brian m. carlson","fromEmail":"sandals@crustytoothpaste.net","sentAt":"2021-10-27T22:07:59Z","receivedAt":"2021-10-27T22:08:09Z","isPatch":false,"sender":{"key":"sandals@crustytoothpaste.net","avatar":"https://avatars.githubusercontent.com/u/497054?v=4"},"body":"On 2021-10-27 at 19:03:49, Peter Hunkeler wrote:\n> Hi,\n> Git seems to behave inconsistently when creating and \"git add\"ing\n> content (files) from within a pre-commit hook. It claims there is\n> \"nothing to commit\", if the stating area was empty before the commit\n> command. Otherwise, the new content becomes part of the commit. See\n> details on how to reproduce and a log of the individual steps below.\n> \n> Regards\n> Peter\n> \n> \n> === Amended Git bug report\n> =============================================================================================\n> Thank you for filling out a Git bug report!\n> Please answer the following questions to help us understand your issue.\n> \n> What did you do before the bug happened? (Steps to reproduce your issue)\n> \n> I'm quite new to using git, so please bear with me should I mix up some\n> terminology.\n> \n> I need some new file to be created at each commit. The new file must\n> become part of the commit.\n> I thought a git pre-commit hook would be the appropriate place. While\n> the file is created as desired,\n> git does *not* include this new file in the commit, when there is\n> nothing else in the staging area. It\n> reports the new file as being untracked, and says nothing added to\n> commit. A git status immediately\n> thereafter does, however, show the new file in the staging area. If I\n> run another commit just now, another\n> new file is created as expected, but this time, git adds them both to\n> the commit. This can be reliably\n> reproduced by repeating 'git commit -m \"empty\"', and every second time,\n> the commit is done.\n> \n> Further testing shows that the newly created file *is* added to the\n> commit, *if* at least one other change\n> was registered to be commited (git add some time before the git commit).\n\nYes, this occurs because the first thing we do is invoke the pre-commit\nhook.  It passes, and then we consider various reasons why we should not\ncommit: the hook failed, there's nothing to commit, etc.  We discover\none since we haven't re-read the index yet and last we saw there was\nnothing to commit, so we abort.\n\nThere's a giant comment before we re-read the index that says this:\n\n\t\t/*\n\t\t * Re-read the index as pre-commit hook could have updated it,\n\t\t * and write it out as a tree.  We must do this before we invoke\n\t\t * the editor and after we invoke run_status above.\n\t\t */\n\nThe commit history does not explain why we must do this _after_ invoking\nrun_status, but if the comment is incorrect and we re-read it\nimmediately, then this problem would go away.  I lack the relevant\ncontext to determine whether this is appropriate, but if folks think\nthis is advisable, then I can write up a patch this weekend.  It should\nbe relatively trivial.\n\nI should point out here that it isn't intended for pre-commit hooks to\nbe used this way; they're intended to verify that the commit meets some\nstandards, not to modify it, although it is of course possible to do.\n\nThis will happen to work in your case if you use --allow-empty, which\nwill bypass the \"nothing to commit\" check.\n\n> The git pre-commit hook looks like this (indented for readability, only):\n>     #!/bin/bash\n>     fn=\"folder1\\folder1_file3_$(date +%Y%m%d_%H%M%S).txt\"\n>     echo \"some text\" > $fn\n>     git add $fn\n\nIn general, you want to avoid adding automatically generated files to\nyour repository.  That tends to bloat the repository needlessly and is a\ngreat way to lead to frequent, hard-to-resolve merge conflicts.\n\nYou may also want to read the “How do I use hooks to prevent users from\nmaking certain changes?” in gitfaq(7) and note that hooks can be\nbypassed on developer systems, so whatever changes you make in a hook\naren't guaranteed to be applied unless you're the only one working on\nthe repository.\n-- \nbrian m. carlson (he/him or they/them)\nToronto, Ontario, CA\n"},{"id":"439843","messageId":"YXnVuhyPuFFfJ8zq@coredump.intra.peff.net","threadId":"56795","inReplyTo":"YXnNvyi62j5gcxQV@camp.crustytoothpaste.net","subject":"Re: Git not commiting anything if file created and \"git add\"ed in pre-commit hook is the only file in the staging area","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2021-10-27T22:42:02Z","receivedAt":"2021-10-27T22:42:05Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Oct 27, 2021 at 10:07:59PM +0000, brian m. carlson wrote:\n\n> > Further testing shows that the newly created file *is* added to the\n> > commit, *if* at least one other change\n> > was registered to be commited (git add some time before the git commit).\n> \n> Yes, this occurs because the first thing we do is invoke the pre-commit\n> hook.  It passes, and then we consider various reasons why we should not\n> commit: the hook failed, there's nothing to commit, etc.  We discover\n> one since we haven't re-read the index yet and last we saw there was\n> nothing to commit, so we abort.\n> \n> There's a giant comment before we re-read the index that says this:\n> \n> \t\t/*\n> \t\t * Re-read the index as pre-commit hook could have updated it,\n> \t\t * and write it out as a tree.  We must do this before we invoke\n> \t\t * the editor and after we invoke run_status above.\n> \t\t */\n> \n> The commit history does not explain why we must do this _after_ invoking\n> run_status, but if the comment is incorrect and we re-read it\n> immediately, then this problem would go away.  I lack the relevant\n> context to determine whether this is appropriate, but if folks think\n> this is advisable, then I can write up a patch this weekend.  It should\n> be relatively trivial.\n\nThere's some related discussion of this area in:\n\n  https://lore.kernel.org/git/CADv3qkGq3jA8iXsjhrqfsUX=gW+KOuLyeVgDzmku1tUpsMdvtw@mail.gmail.com/\n\nI don't find it particularly enlightening as to the history, but it does\npoint to other people wanting to re-read before run_status().\n\n-Peff\n"},{"id":"439856","messageId":"xmqqy26erl2a.fsf@gitster.g","threadId":"56795","inReplyTo":"YXnVuhyPuFFfJ8zq@coredump.intra.peff.net","subject":"Re: Git not commiting anything if file created and \"git add\"ed in pre-commit hook is the only file in the staging area","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2021-10-28T01:32:13Z","receivedAt":"2021-10-28T01:32:20Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King <peff@peff.net> writes:\n\n>> The commit history does not explain why we must do this _after_ invoking\n>> run_status, but if the comment is incorrect and we re-read it\n>> immediately, then this problem would go away.  I lack the relevant\n>> context to determine whether this is appropriate, but if folks think\n>> this is advisable, then I can write up a patch this weekend.  It should\n>> be relatively trivial.\n>\n> There's some related discussion of this area in:\n>\n>   https://lore.kernel.org/git/CADv3qkGq3jA8iXsjhrqfsUX=gW+KOuLyeVgDzmku1tUpsMdvtw@mail.gmail.com/\n>\n> I don't find it particularly enlightening as to the history, but it does\n> point to other people wanting to re-read before run_status().\n\nAh, OK.  Because we call run_status() to see if there is anything\n\"committable\" is there in the part of the changes that the user\nprepared (before hooks futzed with the index), and reject if (for\nexample) there is nothing to commit, we deliberately refuse the case\nwhere the invoker of \"git commit\" does *nothing* and the only change\nbetween HEAD and the index to be committed after the hook runs is\nwhat was done by the hook.  IOW, the current behaviour was designed\nspecifically to handle the case that started this thread.\n\nInteresting.  I think the reasoning makes sense, and having to say\nallow-empty, and being able to bypass by saying allow-empty, is a\nfeature from the point of view of that design.\n\n\n"},{"id":"439867","messageId":"dd79e443-3bb9-8b83-746b-7db7c4997ee3@gmx.net","threadId":"56795","inReplyTo":"YXnNvyi62j5gcxQV@camp.crustytoothpaste.net","subject":"Re: Git not commiting anything if file created and \"git add\"ed in pre-commit hook is the only file in the staging area","fromName":"Peter Hunkeler","fromEmail":"phunsoft@gmx.net","sentAt":"2021-10-28T12:08:27Z","receivedAt":"2021-10-28T12:08:42Z","isPatch":false,"sender":{"key":"phunsoft@gmx.net","avatar":null},"body":"Am 28.10.2021 um 00:07 schrieb brian m. carlson:\n> I should point out here that it isn't intended for pre-commit hooks to\n> be used this way; they're intended to verify that the commit meets some\n> standards, not to modify it, although it is of course possible to do.\n>\nI can accept that comment. However:\n\n- wouldn't you agree that git should work consistently? It does not in\nthis case. If there is anything to be commited in the index, then the\n\"git add\" from within the pre-commit hook *is* respected in this commit.\nIf there is *nothing* to be commited, except from what was added by the\npre-commit exit, then it is ignored *for this commit*, but it is added\nand will be commited next time. This is inconsistent behaviour.\n\n- if the decision will be *not* to allow adding from within a pre-commit\nhook, then the \"git add\" should be rejected. And the documentation\nshould say so.\n\nI'll have to understand what all the comments from you and others mean\n(still a git newbee).\n\n> In general, you want to avoid adding automatically generated files to\n> your repository.  That tends to bloat the repository needlessly and is a\n> great way to lead to frequent, hard-to-resolve merge conflicts.\n>\nI'm trying to use git to keep track of changes to my website, which uses\nsome framework. The problem is: Some changes modify filesystem entities,\nonly, while other changes modify the content of some mysql tables. So I\nneed to pack an unload of those tables into the commit. I can do this\nmanually (and forget every now and then :-), or I thought the pre-commit\nhook would be a good place to automate this. And, yes, it may well crete\nmerge conflicts.\n\nI understand the pre-commit hook is a local thing, and I have to make\nsure the same is active in all repositories. Definitely not something to\nuse in a widely shared project.\n\nThanks a lot\nPeter\n"},{"id":"440122","messageId":"c5507ba6-6e31-b143-9791-0bcff54acb64@gmx.net","threadId":"56795","inReplyTo":"dd79e443-3bb9-8b83-746b-7db7c4997ee3@gmx.net","subject":"Re: Git not commiting anything if file created and \"git add\"ed in pre-commit hook is the only file in the staging area","fromName":"Peter Hunkeler","fromEmail":"phunsoft@gmx.net","sentAt":"2021-10-30T13:21:14Z","receivedAt":"2021-10-30T13:21:33Z","isPatch":false,"sender":{"key":"phunsoft@gmx.net","avatar":null},"body":"Pardon my ignorance, but I'm unlear as to how to proceed further with my\nissue.\nWhat is the proper process to report a bug, and get a consense whether\nit is accepted or rejected?\n\nRegards\nPeter\n\nAm 28.10.2021 um 14:08 schrieb Peter Hunkeler:\n> Am 28.10.2021 um 00:07 schrieb brian m. carlson:\n>> I should point out here that it isn't intended for pre-commit hooks to\n>> be used this way; they're intended to verify that the commit meets some\n>> standards, not to modify it, although it is of course possible to do.\n>>\n> I can accept that comment. However:\n>\n> - wouldn't you agree that git should work consistently? It does not in\n> this case. If there is anything to be commited in the index, then the\n> \"git add\" from within the pre-commit hook *is* respected in this commit.\n> If there is *nothing* to be commited, except from what was added by the\n> pre-commit exit, then it is ignored *for this commit*, but it is added\n> and will be commited next time. This is inconsistent behaviour.\n>\n> - if the decision will be *not* to allow adding from within a pre-commit\n> hook, then the \"git add\" should be rejected. And the documentation\n> should say so.\n>\n> I'll have to understand what all the comments from you and others mean\n> (still a git newbee).\n>\n>> In general, you want to avoid adding automatically generated files to\n>> your repository.  That tends to bloat the repository needlessly and is a\n>> great way to lead to frequent, hard-to-resolve merge conflicts.\n>>\n> I'm trying to use git to keep track of changes to my website, which uses\n> some framework. The problem is: Some changes modify filesystem entities,\n> only, while other changes modify the content of some mysql tables. So I\n> need to pack an unload of those tables into the commit. I can do this\n> manually (and forget every now and then :-), or I thought the pre-commit\n> hook would be a good place to automate this. And, yes, it may well crete\n> merge conflicts.\n>\n> I understand the pre-commit hook is a local thing, and I have to make\n> sure the same is active in all repositories. Definitely not something to\n> use in a widely shared project.\n>\n> Thanks a lot\n> Peter\n\n"},{"id":"440127","messageId":"4c88e2ae-e42f-491a-2b97-aa1f92c392d5@kdbg.org","threadId":"56795","inReplyTo":"c5507ba6-6e31-b143-9791-0bcff54acb64@gmx.net","subject":"Re: Git not commiting anything if file created and \"git add\"ed in pre-commit hook is the only file in the staging area","fromName":"Johannes Sixt","fromEmail":"j6t@kdbg.org","sentAt":"2021-10-30T16:44:54Z","receivedAt":"2021-10-30T16:44:58Z","isPatch":false,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"Am 30.10.21 um 15:21 schrieb Peter Hunkeler:\n> Pardon my ignorance, but I'm unlear as to how to proceed further with my\n> issue.\n> What is the proper process to report a bug, and get a consense whether\n> it is accepted or rejected?\n\nWriting a message to this mailing list is all the process that exists.\nYou brought forward arguments in a civil manner why you think the\ncurrent behavior is not correct. That's appreciated. However, it doesn't\nautomatically mean that something will be changed.\n\nIn your particular case...\n\n> Am 28.10.2021 um 14:08 schrieb Peter Hunkeler:\n>> Am 28.10.2021 um 00:07 schrieb brian m. carlson:\n>>> I should point out here that it isn't intended for pre-commit hooks to\n>>> be used this way; they're intended to verify that the commit meets some\n>>> standards, not to modify it, although it is of course possible to do.\n>>>\n>> I can accept that comment. However:\n>>\n>> - wouldn't you agree that git should work consistently? It does not in\n>> this case. If there is anything to be commited in the index, then the\n>> \"git add\" from within the pre-commit hook *is* respected in this commit.\n>> If there is *nothing* to be commited, except from what was added by the\n>> pre-commit exit, then it is ignored *for this commit*, but it is added\n>> and will be commited next time. This is inconsistent behaviour.\n>>\n>> - if the decision will be *not* to allow adding from within a pre-commit\n>> hook, then the \"git add\" should be rejected. And the documentation\n>> should say so.\n\n... it is clearly stated (and brian repeated it) that the pre-commit\nhook is intended to check the commit for \"correctness\" (whatever that\nmeans for the project). `git add` is not automatically forbidden,\nbecause it would be an unreasonable engineering effort to forbid things\nthat \"do not merely check\" the commit. (What if a user has to use `git\nadd` as part of some exotic check? For example, it is possible to `git\nadd` to some temporary throw-away index that is different from the one\nthat is about to be committed.)\n\nEven though the documentation does not say explicitly that the commit\nmust not be changed, it is implicit in the stated intent (that the\ncommit is only checked). Depending on that some particular behavior\nworks for you sometimes is then your own business, and when it breaks\nyou get to keep both parts.\n\nIn conclusion, the pre-commit hook behaves as designed and nothing has\nto be changed.\n\n-- Hannes\n"},{"id":"440140","messageId":"xmqqlf2adx3e.fsf@gitster.g","threadId":"56795","inReplyTo":"4c88e2ae-e42f-491a-2b97-aa1f92c392d5@kdbg.org","subject":"Re: Git not commiting anything if file created and \"git add\"ed in pre-commit hook is the only file in the staging area","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2021-10-30T21:25:09Z","receivedAt":"2021-10-30T21:25:40Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Sixt <j6t@kdbg.org> writes:\n\n> Even though the documentation does not say explicitly that the commit\n> must not be changed, it is implicit in the stated intent (that the\n> commit is only checked). Depending on that some particular behavior\n> works for you sometimes is then your own business, and when it breaks\n> you get to keep both parts.\n\nThe above matches my _intention_ for the pre-commit hook when I\nadded it in 2005, but there were enough people who wanted to abuse\nthe interface that it no longer exactly matches the reality.  It has\nbeen made usable to inspect the changes (which is the original\npurpose of the hook) and in addition, apply mechanical fixes on top,\nbefore making the commit.\n\nThe story so far, however, is that the scenario that started this\nthread is not even that, if I understand it correctly.  The question\nis: what should happen when *nothing* is different between the HEAD\nand the index, the user types \"$ git commit\" (no pathspec, no\nnothing, commit the index as-is, no --allow-empty option), and the\npre-commit mucks with the index to \"fix\" the content in the index.\n\nBecause we check if there is anything to commit before we invoke the\npre-commit hook and then reject an empty commit based on that, we\nsuccessfully reject the attempt to commit.  This is in line even\nwith the modern intention, as the mucking done by the hook cannot be\n\"fixes\" based on the observation of the changes made to the index by\nthe user (e.g. \"The user tries to add changes, with whitespace\nbreakages, and then pre-commit hook notices.  Instead of rejecting,\nit fixes the whitespace issues for the user\" is the justifying use\ncase behind the looser than the original \"check only, no touching\"\ndefinition).  So ...\n\n> In conclusion, the pre-commit hook behaves as designed and nothing has\n> to be changed.\n\n... in conclusion, pre-commit is *not* a place to make such a change\nthat may be created by a script even when there is no human\ninitiated change, and \"git commit\" is behaving as designed.\n\nBut there are two things that are not solved yet.\n\n * It is *not* the ultimate goal of the OP to \"use\" pre-commit\n   hook.  The goal of OP is to find a workflow ingredient where\n   changes other than human initiated ones are committed at the same\n   time human user tries to commit changes created by human.  So if\n   pre-commit is the wrong tool to use for that purpose, what is it?\n\n   I suspect that there is no built-in way to do this, and I am not\n   sure if it is a good idea to add such a feature to the tool---as\n   some have already noted in the discussion, it may encourage a bad\n   workflow to include such non-human-created artifacts to human\n   initiated commit.  I don't know.\n\n * If we do not consider changes made by pre-commit hook to count as\n   \"without --allow-empty, an empty commit is rejected\" logic, why\n   do we even call the hook in the first place in such a case?  I\n   think there is a room for improvement on our side---perhaps we\n   can make \"git commit\" fail much earlier in such a case without\n   calling the pre-commit hook.\n\nThanks for the discussion so far.\n\n"},{"id":"440303","messageId":"a7bdab08-70a5-5dcb-1740-190983ac0848@gmx.net","threadId":"56795","inReplyTo":"xmqqlf2adx3e.fsf@gitster.g","subject":"Re: Git not commiting anything if file created and \"git add\"ed in pre-commit hook is the only file in the staging area","fromName":"Peter Hunkeler","fromEmail":"phunsoft@gmx.net","sentAt":"2021-11-02T13:13:40Z","receivedAt":"2021-11-02T13:13:57Z","isPatch":false,"sender":{"key":"phunsoft@gmx.net","avatar":null},"body":"Am 30.10.2021 um 23:25 schrieb Junio C Hamano:\n> Johannes Sixt <j6t@kdbg.org> writes:\n>\n>> Even though the documentation does not say explicitly that the commit\n>> must not be changed, it is implicit in the stated intent (that the\n>> commit is only checked). Depending on that some particular behavior\n>> works for you sometimes is then your own business, and when it breaks\n>> you get to keep both parts.\n> The above matches my _intention_ for the pre-commit hook when I\n> added it in 2005, but there were enough people who wanted to abuse\n> the interface that it no longer exactly matches the reality.  It has\n> been made usable to inspect the changes (which is the original\n> purpose of the hook) and in addition, apply mechanical fixes on top,\n> before making the commit.\n>\n> The story so far, however, is that the scenario that started this\n> thread is not even that, if I understand it correctly.  The question\n> is: what should happen when *nothing* is different between the HEAD\n> and the index, the user types \"$ git commit\" (no pathspec, no\n> nothing, commit the index as-is, no --allow-empty option), and the\n> pre-commit mucks with the index to \"fix\" the content in the index.\n>\n> Because we check if there is anything to commit before we invoke the\n> pre-commit hook and then reject an empty commit based on that, we\n> successfully reject the attempt to commit.  This is in line even\n> with the modern intention, as the mucking done by the hook cannot be\n> \"fixes\" based on the observation of the changes made to the index by\n> the user (e.g. \"The user tries to add changes, with whitespace\n> breakages, and then pre-commit hook notices.  Instead of rejecting,\n> it fixes the whitespace issues for the user\" is the justifying use\n> case behind the looser than the original \"check only, no touching\"\n> definition).  So ...\n>\n>> In conclusion, the pre-commit hook behaves as designed and nothing has\n>> to be changed.\n> ... in conclusion, pre-commit is *not* a place to make such a change\n> that may be created by a script even when there is no human\n> initiated change, and \"git commit\" is behaving as designed.\n>\n> But there are two things that are not solved yet.\n>\n>   * It is *not* the ultimate goal of the OP to \"use\" pre-commit\n>     hook.  The goal of OP is to find a workflow ingredient where\n>     changes other than human initiated ones are committed at the same\n>     time human user tries to commit changes created by human.  So if\n>     pre-commit is the wrong tool to use for that purpose, what is it?\n>\n>     I suspect that there is no built-in way to do this, and I am not\n>     sure if it is a good idea to add such a feature to the tool---as\n>     some have already noted in the discussion, it may encourage a bad\n>     workflow to include such non-human-created artifacts to human\n>     initiated commit.  I don't know.\nBeing the OP of this thread, I have learnt that a) my case of\nincorporating database changes very atypical to git, and b) automating\nthe inclusion of such changes *at commit time* is not the best option.\nIn my case, it is easy to run this very pre-commit script manually\nbefore the commit. I don't see any benefit of adding whatever \"tool\" to\nsupport this special case.\n>   * If we do not consider changes made by pre-commit hook to count as\n>     \"without --allow-empty, an empty commit is rejected\" logic, why\n>     do we even call the hook in the first place in such a case?  I\n>     think there is a room for improvement on our side---perhaps we\n>     can make \"git commit\" fail much earlier in such a case without\n>     calling the pre-commit hook.\nThis would make the bevahiour to be consistent, without officialy\nsupporting or rejecting  \"git xyz\" from withing the hook. Hopefully not\ntoo complex to implement.\n\nThanks\nPeter\n"}]}