git/list[1] front-page[2] threads[3] people[4] search[5] about
 

obsolete index in wt_status_print after pre-commit hook runs

From
AKAndrew Keller <andrew.keller@covenanteyes.com>
Date
Jul 15, 2016, 16:34 UTC
Message-ID
<5988D847-25A2-4997-9601-083772689879@covenanteyes.com>
Hi everyone,
I have observed an interesting scenario.  Here are example reproduction steps:
1. new repository
2. create new pre-commit hook that invokes `git mv one two`
3. touch one
4. git add one
5. git commit
Expected outcome: In the commit message template, I expect to see “Changes to be committed: new file: two"
Found outcome: In the commit message template, I see “Changes to be committed: new file: one"
This behavior seems to be reproducible in versions 2.9.1, 2.8.1, 2.0.0, and 1.6.0.
Skip the next 3 paragraphs if you are in a hurry.

I pulled out the source for version 2.9.1 and briefly skimmed how run_commit and prepare_to_commit work. It seems that Git already understands that a pre-commit hook can change the index, and it rereads the index before running the prepare-commit-msg hook: https://github.com/git/git/blob/v2.9.1/builtin/commit.c#L941-L951

During the prepare-commit-msg hook, it seems that the index (according to Git commands) is correct and up-to-date, but the textual message inside the commit message template is out-of-date (it references the file `one` as a change to be committed).

In builtin/commit.c, it seems that the commit message template is rendered immediately after the pre-commit hook is ran, and immediately before the index is reread. If I move the small block of code that rereads the index up, to just after the pre-commit hook is ran, the commit message template seems to be as I would expect, both in .git/COMMIT_EDITMSG during the prepare-commit-msg hook and in the editor for the commit message itself.

I am putting together a 2-patch series that includes a failing test, and then this change (which fixes the test), but while I do that, I figure I may as well ping the community to make sure that this behavior is not intentional. I’d wager that this change is for the better, but since this behavior has been around so long (I stopped checking at 1.6.0), it doesn’t hurt to make sure.

Any comments, concerns, or advice?
Thanks,
 - Andrew Keller
Next: Junio C Hamano
Message 1 of 13 in “obsolete index in wt_status_print after pre-commit hook runs”
  1. Andrew KellerJul 15, 2016
  2. Junio C HamanoJul 15, 2016
  3. Andrew KellerJul 15, 2016
  4. Junio C HamanoJul 15, 2016
  5. Andrew KellerJul 15, 2016
  6. Andrew KellerJul 15, 2016
  7. Junio C HamanoJul 15, 2016
  8. Junio C HamanoJul 15, 2016
  9. Andrew KellerJul 16, 2016
  10. Andrew KellerAug 3, 2016
  11. Junio C HamanoAug 4, 2016
  12. Andrew KellerAug 5, 2016
  13. Andrew KellerJul 16, 2016

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.