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

Re: [PATCH v3] apply: --intent-to-add should imply --index

From
Raymond E. Pasco <ray@ameretat.dev>
Date
May 3, 2025, 03:51 UTC
Message-ID
<4e2szrowd43w6lrzawqtddamdxvp6ke65jkzmdoru4gjin7xhn@kaqe7skrktgt>
In-Reply-To
<ED60E13F-F9D4-4261-8C85-29AC771B5D54@gmail.com>

Intents to add are a tricky part of the system; I fixed them up some time ago for `add -p` which uses apply.c machinery, but not for `apply -N`, which seems to have never worked since its introduction in Git 2.19.

To recap how this all works, apply has three modes: with no flag, it applies a diff to the physical files in the worktree; with --index it applies a diff to both the physical files in the worktree and to the index, and with --cached it applies to the index but *not* the physical files in the worktree.

--intent-to-add / -N is intended to apply only to the first of these modes; this makes sense, because an intent to add is meant to behave like a diff not added to the index. However, the intent to add lives in the index; Git just behaves as though it were a worktree change not in the index.

The behavior `apply -N` actually exhibits is that it clobbers the index with a new index containing *only* the contents of the diff, nothing else; my guess is that it was only tested against repositories with entirely empty trees. If the tree is not empty, then of course an index with only the intent to add and nothing else shows up as every file in the tree being deleted.

The patch discussed here (the headers for the thread seem broken, but the message id is <20211106114202.3486969-1-aclopte@gmail.com>) does seem like a mostly complete fix for the issue. However, the message is entirely wrong and confused about how any of this works, which is likely why the patch fell through the cracks. (Of course --intent-to-add can't imply --index, they are mutually exclusive options.)

However, the code appears entirely correct. The combination of --cached with -N doesn't work, despite the message claiming it does, but it can't possibly work because it includes the file in the index, so it can't include it as an intent to add in the index. So this just merits a note that --intent-to-add is mutually exclusive with both --index and --cached.

If the original author (Johannes Altmanninger) isn't around or doesn't want to, I can clean this patch up for resubmission.

Previous: Ryan HodgesNext: Raymond E. Pasco
Message 5 of 14 in “RE: [PATCH v3] apply: --intent-to-add should imply --index”
  1. Jason ChoMay 1, 2025
  2. Kristoffer HaugsbakkMay 1, 2025
  3. Junio C HamanoMay 1, 2025
  4. Ryan HodgesMay 2, 2025
  5. Raymond E. PascoMay 3, 2025
  6. Raymond E. PascoMay 3, 2025
  7. 0/5 apply: fix apply --intent-to-addRaymond E. Pasco, May 11, 2025
  8. 1/5 apply: error on --intent-to-add outside gitdirRaymond E. Pasco, May 11, 2025
  9. 2/5 apply: read in the index in --intent-to-add modeRaymond E. Pasco, May 11, 2025
  10. Raymond E. PascoMay 12, 2025
  11. Jason ChoMay 13, 2025
  12. 3/5 apply: only write intents to add for new filesRaymond E. Pasco, May 11, 2025
  13. 4/5 t4140: test apply --intent-to-add interactionsRaymond E. Pasco, May 11, 2025
  14. 5/5 apply docs: clarify wording for --intent-to-addRaymond E. Pasco, May 11, 2025

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.