{"version":"2.1.281","anchor":"git-snapshot-folds-a-split-index-before-reading-it","canonical_anchor":"git-snapshot-folds-a-split-index-before-reading-it","heading":"Git snapshots and restores now fold a split index before using it","tier":"notice","area":"Git","url":"https:\/\/changelogs.core-directive.com\/v\/2.1.281\/e\/git-snapshot-folds-a-split-index-before-reading-it","release_url":"https:\/\/changelogs.core-directive.com\/v\/2.1.281","markdown":"### Git snapshots and restores now fold a split index before using it\n\nClaude Code now runs git update-index --no-split-index on a copied git index that may be split before reading it\n\n**Unclear.** The finding does not say when Claude Code takes these git snapshots.\n\n**What**\n\nGit's index is the file that records what is staged for the next commit. With the `core.splitIndex` setting, git stores the index in two files instead of one. Claude Code now handles this case when it takes a snapshot of your repository and after it applies or restores changes.\n\n- A helper that runs after git apply or restore now reports `maybeSplit`. This is set when files were processed and the index shows a split-index marker, and also when the check itself hits an error. Before, the helper returned nothing.\n\n- When the copied index may be split, the snapshot code runs `git update-index --no-split-index` to merge it back into one file. If that fails, the snapshot stops with the error \"could not fold the copied index whole\".\n\n- The snapshot now reads the current commit (HEAD) before it processes unmerged entries, which are files with unresolved merge conflicts. Before, it read HEAD afterwards.\n\n**Why**\n\nIn repositories that use `core.splitIndex`, snapshots and restores work from the full index instead of only part of it. If the index cannot be merged back into one file, the snapshot now fails with an error.\n\n- Area: Git\n- Tier: You'll notice\n- Useful: 1\/5\n- Signal: 1\/5"}