summaryrefslogtreecommitdiff
path: root/unpack-trees.c
diff options
context:
space:
mode:
authorLibravatar Junio C Hamano <gitster@pobox.com>2019-11-13 10:30:05 +0900
committerLibravatar Junio C Hamano <gitster@pobox.com>2019-11-13 10:30:26 +0900
commit61eea521fef11c6878a4157bcc0fca6e981a58b2 (patch)
tree5c710ba17c64c1a328241783244b8414f2900dfc /unpack-trees.c
parentt7519-status-fsmonitor: improve comments (diff)
downloadtgif-61eea521fef11c6878a4157bcc0fca6e981a58b2.tar.xz
fsmonitor: do not compare bitmap size with size of split index
3444ec2e ("fsmonitor: don't fill bitmap with entries to be removed", 2019-10-11) added a handful of sanity checks that make sure that a bit position in fsmonitor bitmap does not go beyond the end of the index. As each bit in the bitmap corresponds to a path in the index, this is the right check most of the time. Except for the case when we are in the split-index mode and looking at a delta index that is to be overlayed on the base index but before the base index has actually been merged in, namely in read_ and write_fsmonitor_extension(). In these codepaths, the entries in the split/delta index is typically a small subset of the entire set of paths (otherwise why would we be using split-index?), so the bitmap used by the fsmonitor is almost always larger than the number of entries in the partial index, and the incorrect comparison would trigger the BUG(). Reported-by: Utsav Shah <ukshah2@illinois.edu> Helped-by: Kevin Willford <Kevin.Willford@microsoft.com> Helped-by: William Baker <William.Baker@microsoft.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Diffstat (limited to 'unpack-trees.c')
0 files changed, 0 insertions, 0 deletions