On 2021-10-27 at 19:03:49, Peter Hunkeler wrote: > Hi, > Git seems to behave inconsistently when creating and "git add"ing > content (files) from within a pre-commit hook. It claims there is > "nothing to commit", if the stating area was empty before the commit > command. Otherwise, the new content becomes part of the commit. See > details on how to reproduce and a log of the individual steps below. > > Regards > Peter > > > === Amended Git bug report > ============================================================================================= > Thank you for filling out a Git bug report! > Please answer the following questions to help us understand your issue. > > What did you do before the bug happened? (Steps to reproduce your issue) > > I'm quite new to using git, so please bear with me should I mix up some > terminology. > > I need some new file to be created at each commit. The new file must > become part of the commit. > I thought a git pre-commit hook would be the appropriate place. While > the file is created as desired, > git does *not* include this new file in the commit, when there is > nothing else in the staging area. It > reports the new file as being untracked, and says nothing added to > commit. A git status immediately > thereafter does, however, show the new file in the staging area. If I > run another commit just now, another > new file is created as expected, but this time, git adds them both to > the commit. This can be reliably > reproduced by repeating 'git commit -m "empty"', and every second time, > the commit is done. > > Further testing shows that the newly created file *is* added to the > commit, *if* at least one other change > was registered to be commited (git add some time before the git commit). Yes, this occurs because the first thing we do is invoke the pre-commit hook. It passes, and then we consider various reasons why we should not commit: the hook failed, there's nothing to commit, etc. We discover one since we haven't re-read the index yet and last we saw there was nothing to commit, so we abort. There's a giant comment before we re-read the index that says this: /* * Re-read the index as pre-commit hook could have updated it, * and write it out as a tree. We must do this before we invoke * the editor and after we invoke run_status above. */ The commit history does not explain why we must do this _after_ invoking run_status, but if the comment is incorrect and we re-read it immediately, then this problem would go away. I lack the relevant context to determine whether this is appropriate, but if folks think this is advisable, then I can write up a patch this weekend. It should be relatively trivial. I should point out here that it isn't intended for pre-commit hooks to be used this way; they're intended to verify that the commit meets some standards, not to modify it, although it is of course possible to do. This will happen to work in your case if you use --allow-empty, which will bypass the "nothing to commit" check. > The git pre-commit hook looks like this (indented for readability, only): > #!/bin/bash > fn="folder1\folder1_file3_$(date +%Y%m%d_%H%M%S).txt" > echo "some text" > $fn > git add $fn In general, you want to avoid adding automatically generated files to your repository. That tends to bloat the repository needlessly and is a great way to lead to frequent, hard-to-resolve merge conflicts. You may also want to read the “How do I use hooks to prevent users from making certain changes?” in gitfaq(7) and note that hooks can be bypassed on developer systems, so whatever changes you make in a hook aren't guaranteed to be applied unless you're the only one working on the repository. -- brian m. carlson (he/him or they/them) Toronto, Ontario, CA
Attachment:
signature.asc
Description: PGP signature
