git-internal v0.10.4

Release date: 2026-10-27 · Crate: git-internal 0.10.4 · Full changelog: CHANGELOG.md

git-internal v0.10.4 fixes a data-integrity bug in index writing reported in #184: every newly created index entry was marked assume-unchanged.

Fixed

Flags::new() no longer sets assume_valid (#184). Every entry built by IndexEntry::new, IndexEntry::new_from_file and IndexEntry::new_from_blob was previously written with CE_VALID (0x8000, Git's assume-unchanged bit). Git honours that bit unconditionally and skips the worktree stat. Any Git reading an index written by this crate silently ignored modifications and deletions: git status and git diff showed nothing, and git commit -a left changes out. Strict bit-for-bit comparisons against Git-generated indexes also failed. Affected versions: 0.10.2 and 0.10.3, plus every earlier release with the same Flags::new() default.
Reading is unchanged. A CE_VALID bit already present on disk is still preserved when the index is read and written back, the same as Git (update-index --refresh does not clear it either).

The default of Flags::new().assume_valid is now false. Callers that really want the assume-unchanged bit must set entry.flags.assume_valid = true explicitly.
Indexes written by earlier versions keep the bit after loading. A downstream that does not support assume-unchanged semantics (such as Libra, see libra-tools/libra#637) should clear it when loading or saving.

new_entries_do_not_set_assume_valid checks Flags::new() and all three IndexEntry constructors.
assume_valid_is_written_only_when_explicitly_set reads the raw on-disk flags word. An ordinary entry is written without 0x8000. An entry with an explicit assume_valid = true keeps the bit on disk and after reading back.

Full diff: v0.10.3...v0.10.4