Christian Couder <christian.couder@xxxxxxxxx> writes: > The design is similar as the previous work that introduced > "core.untrackedCache". > > The new "core.splitIndex" configuration option can be either true, > false or undefined which is the default. > > When it is true, the split index is created, if it does not already > exists, when the index is read. When it is false, the split index is > removed if it exists, when the index is read. Otherwise it is left as > is. I admit I haven't thought it through, but this sounds OK. > Along with this new configuration variable, the two following options > are also introduced: > > - splitIndex.maxPercentChange > > This is to avoid having too many changes accumulating in the split > index while in split index mode. The git-update-index > documentation says: > > If split-index mode is already enabled and `--split-index` is > given again, all changes in $GIT_DIR/index are pushed back to > the shared index file. > > but it is probably better to not expect the user to think about it > and to have a mechanism that pushes back all changes to the shared > index file automatically when some threshold is reached. > > The default threshold is when the number of entries in the split > index file reaches 20% (by default) of the number of entries in > the shared index file. The new "splitIndex.maxPercentChange" > config option lets people tweak this value. OK. > - splitIndex.sharedIndexExpire > > To make sure that old sharedindex files are eventually removed > when a new one has been created, we "touch" the shared index file > every time it is used by a new split index file. Then we can > delete shared indexes with an mtime older than one week (by > default), when we create a new shared index file. The new > "splitIndex.sharedIndexExpire" config option lets people tweak > this grace period. I do not quite understand this justification. Doesn't each of the "this hold only changes since the base index file" files have a backpointer that names the base index file it is a delta against? Is it safe to remove a base index file when there is still a split index file that points at it? IOW, I do not see why it can be safe for the expiration decision to be based on timestamp (I would understand it if it were based on a refcnt, though).