Git Index Inspector

Almost always because the entry carries assume-unchanged (the on-disk bit git calls CE_VALID) or skip-worktree. Both tell git it may trust the index and skip the lstat comparison for that path, and both survive in the index until something clears them, which is why the effect looks permanent and follows the repository rather than your editor. They mean different things — assume-unchanged is a promise you make about a slow filesystem, skip-worktree is a statement that the file is deliberately absent or locally modified and should be left alone — but the symptom is identical. This page counts them and marks the entries carrying them, so you can find the path and run git update-index --no-assume-unchanged or --no-skip-worktree on it.

Each entry caches ctime, mtime, device, inode, uid, gid, mode and size from the last time git looked at the working-tree file. On the next status git calls lstat() and compares: if every cached field still matches, the file cannot have changed and git skips reading and hashing it, which is what makes status fast in a big repository. All of the fields are truncated to 32 bits, so they are approximations by design. An entry whose whole stat block is zero has never been compared with a real file — that is what git update-index --index-info and the entries of a conflict produce — so it is shown as having no stat data rather than as a timestamp in 1970, which would be a fabrication.

Version 2 is the baseline. Git writes version 3 the moment any entry needs the extended flag word, which is the only place skip-worktree and intent-to-add can live, and it silently drops back to 2 when the last such entry goes away — so marking one file with skip-worktree rewrites the whole file in a different version. Version 4 is opt-in (git update-index --index-version 4) and compresses each path against the previous one, saving real space in a repository with deep directory trees at the cost of making the file readable only front to back. All three are read here, and the version is taken from the header rather than guessed.

Each entry costs about 62 bytes plus its path, so a hundred thousand files is only a handful of megabytes; anything much larger is usually an extension. The untracked cache (UNTR) stores a directory-by-directory record of everything not tracked and grows with the junk in your working tree. The cached tree (TREE) stores one record per directory. On a repository with a huge number of files git may also be using a split index, where the bulk lives in .git/sharedindex.<id> and the file you opened is mostly a link extension. The extensions table here shows the size of each one, which is the fastest way to see which is responsible.

The last twenty bytes (thirty-two in a SHA-256 repository) are a hash of everything before them, written every time git rewrites the file. It catches truncation and corruption — a crash mid-write, a bad disk, a partial copy — but not deliberate tampering, since anyone editing the file can recompute it. If it does not match, git refuses to use the index at all. That is recoverable: the index holds no content of its own, so deleting it and running git reset rebuilds it from HEAD. What you lose is the arrangement — which paths were staged, and any intent-to-add entries — not the objects, which are already in .git/objects. One exception: with index.skipHash, which feature.manyFiles turns on, git writes twenty zero bytes here and skips the hash entirely, so an all-zero trailer is shown as not computed rather than as a mismatch.

No. The index is read with the browser's File API and decoded by JavaScript in the page; there is no server side to send it to. That matters more here than for most formats, because .git/index is a complete list of the paths in a private repository along with the hash of every staged file — the sort of thing that should not be pasted into a web form. You can load this page, disconnect from the network, and everything still works.