This state is a bit special, so deserves its own topic. If we are
IN_MEMORY_HASH_MODIFIED, we only write out the dirstate if enough records
have been updated. The idea is that if we would save future I/O by writing
an updated dirstate, then we should do so. The threshold for this is set
by “worth_saving_limit”. The default is that at least 10 entries must be
updated in order to consider the dirstate file worth updating.

Going one step further, newly added files, symlinks, and directory entries
updates are treated specially. We know that we will always stat all
entries in the tree so that we can observe if they have changed. In the
case of directories, all the information we know about them is just from
that stat value. There is no extra content to read. So an update directory
entry doesn’t cause us to update to IN_MEMORY_HASH_MODIFIED. However, if
there are other modifications worth saving, we will go ahead and save the
directory entry update at the same time.

Similarly, symlink targets are commonly stored in the inode entry
directly. So once we have stat’ed the symlink, we already have its target
information in memory. The one caveat is if we used to think an object was
a file, and it became a directory or symlink, then we will treat it as
worth saving.

In the case of newly added files, we never have to read their content to
know that they are different from the basis tree. So saving the updated
information also won’t save a future read.