On Thu, Sep 6, 2018 at 4:48 AM SZEDER Gábor <szeder....@gmail.com> wrote: > > Ever since the split index feature was introduced [1], refreshing a > split index is prone to a variant of the classic racy git problem. > > Consider the following sequence of commands updating the split index > when the shared index contains a racily clean cache entry, i.e. an > entry whose cached stat data matches with the corresponding file in > the worktree and the cached mtime matches that of the index: > > echo "cached content" >file > git update-index --split-index --add file > echo "dirty worktree" >file # size stays the same! > # ... wait ... > git update-index --add other-file > > Normally, when a non-split index is updated, then do_write_index() > (the function responsible for writing all kinds of indexes, "regular", > split, and shared) recognizes racily clean cache entries, and writes > them with smudged stat data, i.e. with file size set to 0. When > subsequent git commands read the index, they will notice that the > smudged stat data doesn't match with the file in the worktree, and > then go on to check the file's content. > > In the above example, however, in the second 'git update-index' > prepare_to_write_split_index() gathers all cache entries that should > be written to the new split index. Alas, this function never looks > out for racily clean cache entries, and since the file's stat data in > the worktree hasn't changed since the shared index was written, it > won't be replaced in the new split index. Consequently, > do_write_index() doesn't even get this racily clean cache entry, and > can't smudge its stat data. Subsequent git commands will then see > that the index has more recent mtime than the file and that the (not > smudged) cached stat data still matches with the file in the worktree, > and, ultimately, will erroneously consider the file clean. > > Modify prepare_to_write_split_index() to recognize racily clean cache > entries, and mark them to be added to the split index. This way > do_write_index() will get these racily clean cache entries as well, > and will then write them with smudged stat data to the new split > index.
Ack. I was aware of the first half of of the racy solution but did not pay attention to this smudging business. I wonder if untracked cache is also racy like this. It also only has half the racy solution because I only knew that much. I'll check this later. > Note that after this change if the index is split when it contains a > racily clean cache entry, then a smudged cache entry will be written > both to the new shared and to the new split indexes. This doesn't > affect regular git commands: as far as they are concerned this is just > an entry in the split index replacing an outdated entry in the shared > index. It did affect a few tests in 't1700-split-index.sh', though, > because they actually check which entries are stored in the split > index; the previous patch made the necessary adjustments. And racily > clean cache entries and index splitting are rare enough to not worry > about the resulting duplicated smudged cache entries, and the > additional complexity required to prevent them is not worth it. Yes. If we have to make updates (racy or not) we have to make updates, and the version in the shared index becomes obsolete by design. -- Duy
