On Wed, Oct 27, 2021 at 10:07:59PM +0000, brian m. carlson wrote: > > 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. There's some related discussion of this area in: https://lore.kernel.org/git/CADv3qkGq3jA8iXsjhrqfsUX=gW+KOuLyeVgDzmku1tUpsMdvtw@xxxxxxxxxxxxxx/ I don't find it particularly enlightening as to the history, but it does point to other people wanting to re-read before run_status(). -Peff
