2-bit stage (during merge)

    12-bit name length if the length is less than 0xFFF; otherwise 0xFFF
    is stored in this field.

  (Version 3 or later) A 16-bit field, only applicable if the
  "extended flag" above is 1, split into (high to low bits).

    1-bit reserved for future

    1-bit skip-worktree flag (used by sparse checkout)

    1-bit intent-to-add flag (used by "git add -N")

    13-bit unused, must be zero

  Entry path name (variable length) relative to top level directory
    (without leading slash). '/' is used as path separator. The special
    path components ".", ".." and ".git" (without quotes) are disallowed.
    Trailing slash is also disallowed.

    The exact encoding is undefined, but the '.' and '/' characters
    are encoded in 7-bit ASCII and the encoding cannot contain a NUL
    byte (iow, this is a UNIX pathname).

  (Version 4) In version 4, the entry path name is prefix-compressed
    relative to the path name for the previous entry (the very first
    entry is encoded as if the path name for the previous entry is an
    empty string).  At the beginning of an entry, an integer N in the
    variable width encoding (the same encoding as the offset is encoded
    for OFS_DELTA pack entries; see linkgit:gitformat-pack[5]) is stored, followed
    by a NUL-terminated string S.  Removing N bytes from the end of the
    path name for the previous entry, and replacing it with the string S
    yields the path name for this entry.

  1-8 nul bytes as necessary to pad the entry to a multiple of eight bytes
  while keeping the name NUL-terminated.

  (Version 4) In version 4, the padding after the pathname does not
  exist.

  Interpretation of index entries in split index mode is completely
  different. See below for details.

== Extensions

=== Cache tree

  Since the index does not record entries for directories, the cache
  entries cannot describe tree objects that already exist in the object
  database for regions of the index that are unchanged from an existing
  commit. The cache tree extension stores a recursive tree structure that
  describes the trees that already exist and completely match sections of
  the cache entries. This speeds up tree object generation from the index
  for a new commit by only computing the trees that are "new" to that
  commit. It also assists when comparing the index to another tree, such
  as `HEAD^{tree}`, since sections of the index can be skipped when a tree
  comparison demonstrates equality.

  The recursive tree structure uses nodes that store a number of cache
  entries, a list of subnodes, and an object ID (OID). The OID references
  the existing tree for that node, if it is known to exist. The subnodes
  correspond to subdirectories that themselves have cache tree nodes. The
  number of cache entries corresponds to the number of cache entries in
  the index that describe paths within that tree's directory.

  The extension tracks the full directory structure in the cache tree
  extension, but this is generally smaller than the full cache entry list.

  When a path is updated in index, Git invalidates all nodes of the
  recursive cache tree corresponding to the parent directories of that
  path. We store these tree nodes as being "invalid" by using "-1" as the
  number of cache entries. Invalid nodes still store a span of index
  entries, allowing Git to focus its efforts when reconstructing a full
  cache tree.

  The signature for this extension is { 'T', 'R', 'E', 'E' }.

  A series of entries fill the entire extension; each of which
  consists of:

  - NUL-terminated path component (relative to its parent directory);

  - ASCII decimal number of entries in the index that is covered by the
    tree this entry represents (entry_count);

  - A space (ASCII 32);

  - ASCII decimal number that represents the number of subtrees this
    tree has;

  - A newline (ASCII 10); and

  - Object name for the object that would result from writing this span
    of index