Skip to content

format-index Git Command Guide

The git format-index format is the binary file format that stores Git’s staging area information. It tracks cached file states, file modes, object IDs, and timestamps for all files in the working directory.

FieldSizeDescription
Signature4 bytes’D’, ‘I’, ‘R’, ‘C’
Version4 bytesVersion number (2, 3, or 4)
Entry Count4 bytesNumber of index entries
FieldSizeDescription
ctime8 bytesLast change time (creation time for index)
mtime8 bytesLast modification time
dev4 bytesDevice ID
ino4 bytesInode number
mode/perm4 bytesFile permissions and type
uid4 bytesUser ID
gid4 bytesGroup ID
file size4 bytesFile size on disk
object ID20-32 bytesSHA-1 or SHA-256 hash
flags2 bytesName length and flags
file namevariableNUL-terminated file path
  • Core functionality with stat information
  • Basic conflict detection for merging
  • Support for file system capabilities (e.g., symlinks)
  • Optional extension data
  • Enhanced merge conflict tracking
  • Optimized for broken filesystems
  • Skip-worktree and assume-unchanged bits
  • Improved performance for large index files
ExtensionSignaturePurpose
TREE’T’, ‘R’, ‘E’, ‘E’Cached tree object information
REUC’R’, ‘E’, ‘U’, ‘C’Rename conflict information
LINK’l’, ‘i’, ‘n’, ‘k’Split index information
UNTR’U’, ‘N’, ‘T’, ‘R’Untracked cache information
Terminal window
git status

Shows current index state vs working directory.

Terminal window
git add <file>

Stages file changes in the index.

Terminal window
git rm --cached <file>

Unstages file but keeps it in working directory.

Terminal window
git update-index --refresh

Refreshes stat information for tracked files.

Terminal window
git reset --hard HEAD

Resets index and working tree to HEAD.

Terminal window
git ls-files --stage

Displays all files in index with metadata.

Terminal window
git update-index --skip-worktree <path>

Marks path to not watch for changes.

Terminal window
git add <file>

Resolves conflicts by staging resolved content.

How does the index differ from staging area?

Section titled “How does the index differ from staging area?”

The index (staging area) is where files are prepared for commit. It’s a binary file containing file states, object hashes, and metadata.

git add hashes files, creates objects if needed, and updates index entries with new object IDs and stat information.

How do merge conflicts appear in the index?

Section titled “How do merge conflicts appear in the index?”

Merge conflicts store multiple versions (stage 1 = common ancestor, 2 = ours, 3 = theirs) in index. Files aren’t readable until resolved.

What are skip-worktree and assume-unchanged?

Section titled “What are skip-worktree and assume-unchanged?”

skip-worktree ignores files in git status/update checks; assume-unchanged tells Git files haven’t changed (potentially unsafe).

For corrupted index, try git status --porcelain to recreate or use rm .git/index && git reset to rebuild from HEAD.

Why doesn’t Git track empty directories?

Section titled “Why doesn’t Git track empty directories?”

Index only stores file entries; empty directories don’t get entries. Use .gitkeep files to track empty directory placeholders.

Index lets you interactively build commits: stage some changes now, others later, by comparing HEAD vs index vs working tree.

What’s the filesystem monitor extension?

Section titled “What’s the filesystem monitor extension?”

Recent Git versions (experimental) use FSMonitor to watch for file changes, avoiding full directory scans and speeding up large repos.

  1. Staging Control: Enables selective staging of changes before commit
  2. Merge Conflict Resolution: Stores multiple file versions during conflicts
  3. Performance Optimization: Caches file metadata to avoid repeated stats
  4. Sparse Repository Support: Skip-worktree bits for large working directories
  5. Advanced Workflows: Interactive amending and selective reverting
  6. Build System Integration: Provides stable snapshot for automated testing