| Message ID | pull.458.git.1573196960.gitgitgadget@gmail.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | fsmonitor: skip sanity check if the index is split | expand |
"Utsav Shah via GitGitGadget" <gitgitgadget@gmail.com> writes: > At the very least, this patch mitigates an over-eager check for split index > users while maintaining good invariants for the standard case. OK, it sounds more like this "it does not make any sense to compare the position in the fsmonitor bitmap (which covers the entire thing) with the position in just a split part of the index (which covers only the delta over the base index)"? If that is the case, it means that the "check" is even worse than being "over-eager"---it simply is not correct. Thanks, will queue.
Junio C Hamano <gitster@pobox.com> writes: > "Utsav Shah via GitGitGadget" <gitgitgadget@gmail.com> writes: > >> At the very least, this patch mitigates an over-eager check for split index >> users while maintaining good invariants for the standard case. > > OK, it sounds more like this "it does not make any sense to compare > the position in the fsmonitor bitmap (which covers the entire thing) > with the position in just a split part of the index (which covers > only the delta over the base index)"? If that is the case, it means > that the "check" is even worse than being "over-eager"---it simply > is not correct. Having said all that, I wonder if we are doing the right thing with or without 3444ec2e ("fsmonitor: don't fill bitmap with entries to be removed", 2019-10-11) in the split-index mode in the first place. The fact that your "loosen the check and allow 'pos' that identifies a tracked path used by the fsmonitor bitmap to be larger than the size of the istate->cache[]" patch under discussion is needed is that 'pos' may sometimes be larger than isate->cache[] no? Then what happens in this hunk, for example? diff --git a/fsmonitor.c b/fsmonitor.c index 231e83a94d..1f4aa1b150 100644 --- a/fsmonitor.c +++ b/fsmonitor.c @@ -14,8 +14,13 @@ struct trace_key trace_fsmonitor = TRACE_KEY_INIT(FSMONITOR); static void fsmonitor_ewah_callback(size_t pos, void *is) { struct index_state *istate = (struct index_state *)is; - struct cache_entry *ce = istate->cache[pos]; + struct cache_entry *ce; + if (pos >= istate->cache_nr) + BUG("fsmonitor_dirty has more entries than the index (%"PRIuMAX" >= %u)", + (uintmax_t)pos, istate->cache_nr); + + ce = istate->cache[pos]; ce->ce_flags &= ~CE_FSMONITOR_VALID; The istate->cache[] is a dynamic array whose size is managed via the usual ALLOC_GROW() using istate->cache_nr and istate->cache_alloc, whether the split-index feature is in use. When your patch makes a difference, then, doesn't the access to istate->cache[] pick up a random garbage and then flip the bit? Puzzled... In any case, "check is worse than over-eager, it simply is wrong" I wrote in the message I am responding to is totally incorrect, it seems. It smells like lifting the check would just hide the underlying problem under the rug?
> From: git-owner@vger.kernel.org <git-owner@vger.kernel.org> On Behalf > Of Junio C Hamano > Sent: Sunday, November 10, 2019 7:01 PM > > Junio C Hamano <gitster@pobox.com> writes: > > > "Utsav Shah via GitGitGadget" <gitgitgadget@gmail.com> writes: > > > >> At the very least, this patch mitigates an over-eager check for split > >> index users while maintaining good invariants for the standard case. > > > > OK, it sounds more like this "it does not make any sense to compare > > the position in the fsmonitor bitmap (which covers the entire thing) > > with the position in just a split part of the index (which covers only > > the delta over the base index)"? If that is the case, it means that > > the "check" is even worse than being "over-eager"---it simply is not > > correct. > > Having said all that, I wonder if we are doing the right thing with or without > 3444ec2e ("fsmonitor: don't fill bitmap with entries to be removed", 2019-10- > 11) in the split-index mode in the first place. > > The fact that your "loosen the check and allow 'pos' that identifies a tracked > path used by the fsmonitor bitmap to be larger than the size of the istate- > >cache[]" patch under discussion is needed is that 'pos' may sometimes be > larger than isate->cache[] no? Then what happens in this hunk, for example? > > diff --git a/fsmonitor.c b/fsmonitor.c > index 231e83a94d..1f4aa1b150 100644 > --- a/fsmonitor.c > +++ b/fsmonitor.c > @@ -14,8 +14,13 @@ struct trace_key trace_fsmonitor = > TRACE_KEY_INIT(FSMONITOR); static void fsmonitor_ewah_callback(size_t > pos, void *is) { > struct index_state *istate = (struct index_state *)is; > - struct cache_entry *ce = istate->cache[pos]; > + struct cache_entry *ce; > > + if (pos >= istate->cache_nr) > + BUG("fsmonitor_dirty has more entries than the index > (%"PRIuMAX" >= %u)", > + (uintmax_t)pos, istate->cache_nr); > + > + ce = istate->cache[pos]; > ce->ce_flags &= ~CE_FSMONITOR_VALID; > > The istate->cache[] is a dynamic array whose size is managed via the usual > ALLOC_GROW() using istate->cache_nr and istate->cache_alloc, whether the > split-index feature is in use. When your patch makes a difference, then, > doesn't the access to istate->cache[] pick up a random garbage and then flip > the bit? > > Puzzled... In any case, "check is worse than over-eager, it simply is wrong" I > wrote in the message I am responding to is totally incorrect, it seems. It > smells like lifting the check would just hide the underlying problem under the > rug? I agree. The only 2 places that excluding the split-index make sense are in read_fsmonitor_extension and write_fsmonitor_extension because the index_state that is being passing into those methods could be the delta index in which case the number of entries for the fsmonitor bitmap would almost always be more and cause the BUG to be hit which it should not be. The reason it is not needed and should not be in the other 2 places is they are ran from tweak_fsmonitor which is ran at post_read_index_from which is after the base and delta indexes have been loaded into the indes_state and the index_state will have all the entries and if the fsmonitor bitmap is bigger than the number of entries then the BUG should be hit. Kevin
On Mon, Nov 11, 2019 at 8:55 AM Kevin Willford <Kevin.Willford@microsoft.com> wrote: > > > From: git-owner@vger.kernel.org <git-owner@vger.kernel.org> On Behalf > > Of Junio C Hamano > > Sent: Sunday, November 10, 2019 7:01 PM > > > > Junio C Hamano <gitster@pobox.com> writes: > > > > > "Utsav Shah via GitGitGadget" <gitgitgadget@gmail.com> writes: > > > > > >> At the very least, this patch mitigates an over-eager check for split > > >> index users while maintaining good invariants for the standard case. > > > > > > OK, it sounds more like this "it does not make any sense to compare > > > the position in the fsmonitor bitmap (which covers the entire thing) > > > with the position in just a split part of the index (which covers only > > > the delta over the base index)"? If that is the case, it means that > > > the "check" is even worse than being "over-eager"---it simply is not > > > correct. > > > > Having said all that, I wonder if we are doing the right thing with or without > > 3444ec2e ("fsmonitor: don't fill bitmap with entries to be removed", 2019-10- > > 11) in the split-index mode in the first place. > > > > The fact that your "loosen the check and allow 'pos' that identifies a tracked > > path used by the fsmonitor bitmap to be larger than the size of the istate- > > >cache[]" patch under discussion is needed is that 'pos' may sometimes be > > larger than isate->cache[] no? Then what happens in this hunk, for example? > > > > diff --git a/fsmonitor.c b/fsmonitor.c > > index 231e83a94d..1f4aa1b150 100644 > > --- a/fsmonitor.c > > +++ b/fsmonitor.c > > @@ -14,8 +14,13 @@ struct trace_key trace_fsmonitor = > > TRACE_KEY_INIT(FSMONITOR); static void fsmonitor_ewah_callback(size_t > > pos, void *is) { > > struct index_state *istate = (struct index_state *)is; > > - struct cache_entry *ce = istate->cache[pos]; > > + struct cache_entry *ce; > > > > + if (pos >= istate->cache_nr) > > + BUG("fsmonitor_dirty has more entries than the index > > (%"PRIuMAX" >= %u)", > > + (uintmax_t)pos, istate->cache_nr); > > + > > + ce = istate->cache[pos]; > > ce->ce_flags &= ~CE_FSMONITOR_VALID; > > > > The istate->cache[] is a dynamic array whose size is managed via the usual > > ALLOC_GROW() using istate->cache_nr and istate->cache_alloc, whether the > > split-index feature is in use. When your patch makes a difference, then, > > doesn't the access to istate->cache[] pick up a random garbage and then flip > > the bit? > > > > Puzzled... In any case, "check is worse than over-eager, it simply is wrong" I > > wrote in the message I am responding to is totally incorrect, it seems. It > > smells like lifting the check would just hide the underlying problem under the > > rug? > > I agree. The only 2 places that excluding the split-index make sense are in > read_fsmonitor_extension and write_fsmonitor_extension because the > index_state that is being passing into those methods could be the delta index > in which case the number of entries for the fsmonitor bitmap would almost > always be more and cause the BUG to be hit which it should not be. > > The reason it is not needed and should not be in the other 2 places is they > are ran from tweak_fsmonitor which is ran at post_read_index_from which > is after the base and delta indexes have been loaded into the indes_state and > the index_state will have all the entries and if the fsmonitor bitmap is bigger > than the number of entries then the BUG should be hit. Thanks. What exactly is the delta index? Is it the "split" index, vs the shared indices? I was surprised to see cache_nr being zero. My understanding was that cache and cache_nr would always be the materialized version of the entire index, which is clearly incorrect. > > Kevin
On 11/11/19 8:55 AM, Kevin Willford wrote: >> >> The istate->cache[] is a dynamic array whose size is managed via the usual >> ALLOC_GROW() using istate->cache_nr and istate->cache_alloc, whether the >> split-index feature is in use. When your patch makes a difference, then, >> doesn't the access to istate->cache[] pick up a random garbage and then flip >> the bit? >> >> Puzzled... In any case, "check is worse than over-eager, it simply is wrong" I >> wrote in the message I am responding to is totally incorrect, it seems. It >> smells like lifting the check would just hide the underlying problem under the >> rug? > > I agree. The only 2 places that excluding the split-index make sense are in > read_fsmonitor_extension and write_fsmonitor_extension because the > index_state that is being passing into those methods could be the delta index > in which case the number of entries for the fsmonitor bitmap would almost > always be more and cause the BUG to be hit which it should not be. > > The reason it is not needed and should not be in the other 2 places is they > are ran from tweak_fsmonitor which is ran at post_read_index_from which > is after the base and delta indexes have been loaded into the indes_state and > the index_state will have all the entries and if the fsmonitor bitmap is bigger > than the number of entries then the BUG should be hit. > I agree. While working on the 3444ec2e patch I missed that read_fsmonitor_extension and write_fsmonitor_extension could be called with the delta index rather than the full index. I think it makes sense to leave the check in the other two places. Thanks, William
> From: Utsav Shah <ukshah2@illinois.edu> > Sent: Monday, November 11, 2019 10:26 AM > > On Mon, Nov 11, 2019 at 8:55 AM Kevin Willford > <Kevin.Willford@microsoft.com> wrote: > > > > > From: git-owner@vger.kernel.org <git-owner@vger.kernel.org> On > > > Behalf Of Junio C Hamano > > > Sent: Sunday, November 10, 2019 7:01 PM > > > > > > Junio C Hamano <gitster@pobox.com> writes: > > > > > > > "Utsav Shah via GitGitGadget" <gitgitgadget@gmail.com> writes: > > > > > > > >> At the very least, this patch mitigates an over-eager check for > > > >> split index users while maintaining good invariants for the standard > case. > > > > > > > > OK, it sounds more like this "it does not make any sense to > > > > compare the position in the fsmonitor bitmap (which covers the > > > > entire thing) with the position in just a split part of the index > > > > (which covers only the delta over the base index)"? If that is > > > > the case, it means that the "check" is even worse than being > > > > "over-eager"---it simply is not correct. > > > > > > Having said all that, I wonder if we are doing the right thing with > > > or without 3444ec2e ("fsmonitor: don't fill bitmap with entries to > > > be removed", 2019-10- > > > 11) in the split-index mode in the first place. > > > > > > The fact that your "loosen the check and allow 'pos' that identifies > > > a tracked path used by the fsmonitor bitmap to be larger than the > > > size of the istate- > > > >cache[]" patch under discussion is needed is that 'pos' may > > > >sometimes be > > > larger than isate->cache[] no? Then what happens in this hunk, for > example? > > > > > > diff --git a/fsmonitor.c b/fsmonitor.c index 231e83a94d..1f4aa1b150 > > > 100644 > > > --- a/fsmonitor.c > > > +++ b/fsmonitor.c > > > @@ -14,8 +14,13 @@ struct trace_key trace_fsmonitor = > > > TRACE_KEY_INIT(FSMONITOR); static void > > > fsmonitor_ewah_callback(size_t pos, void *is) { > > > struct index_state *istate = (struct index_state *)is; > > > - struct cache_entry *ce = istate->cache[pos]; > > > + struct cache_entry *ce; > > > > > > + if (pos >= istate->cache_nr) > > > + BUG("fsmonitor_dirty has more entries than the index > > > (%"PRIuMAX" >= %u)", > > > + (uintmax_t)pos, istate->cache_nr); > > > + > > > + ce = istate->cache[pos]; > > > ce->ce_flags &= ~CE_FSMONITOR_VALID; > > > > > > The istate->cache[] is a dynamic array whose size is managed via the > > > usual > > > ALLOC_GROW() using istate->cache_nr and istate->cache_alloc, whether > > > the split-index feature is in use. When your patch makes a > > > difference, then, doesn't the access to istate->cache[] pick up a > > > random garbage and then flip the bit? > > > > > > Puzzled... In any case, "check is worse than over-eager, it simply > > > is wrong" I wrote in the message I am responding to is totally > > > incorrect, it seems. It smells like lifting the check would just > > > hide the underlying problem under the rug? > > > > I agree. The only 2 places that excluding the split-index make sense > > are in read_fsmonitor_extension and write_fsmonitor_extension because > > the index_state that is being passing into those methods could be the > > delta index in which case the number of entries for the fsmonitor > > bitmap would almost always be more and cause the BUG to be hit which it > should not be. > > > > The reason it is not needed and should not be in the other 2 places is > > they are ran from tweak_fsmonitor which is ran at post_read_index_from > > which is after the base and delta indexes have been loaded into the > > indes_state and the index_state will have all the entries and if the > > fsmonitor bitmap is bigger than the number of entries then the BUG should > be hit. > > Thanks. What exactly is the delta index? Is it the "split" index, vs the shared > indices? Yes the delta is the same as the split index mentioned here https://git-scm.com/docs/git-update-index#_split_index. > I was surprised to see cache_nr being zero. My understanding was > that cache and cache_nr would always be the materialized version of the > entire index, which is clearly incorrect. Most of the time that is correct but if you look in read_index_from, the index is loaded with the call to ret = do_read_index(istate, path, 0); This will read the index extensions so read_fsmonitor_extension will be called and the cache will only have the entries from the split/delta index. The base/shared index isn't loaded and in the cache until later when merge_base_index(istate); is called which is right before the call to post_read_index_from where tweak_fsmonitor will get called from.
Kevin Willford <Kevin.Willford@microsoft.com> writes: > I agree. The only 2 places that excluding the split-index make sense are in > read_fsmonitor_extension and write_fsmonitor_extension because the > index_state that is being passing into those methods could be the delta index > in which case the number of entries for the fsmonitor bitmap would almost > always be more and cause the BUG to be hit which it should not be. Thanks. Here is what I came up with to tie the loose ends of this thread. -- >8 -- From: Junio C Hamano <gitster@pobox.com> Subject: [PATCH] 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> --- fsmonitor.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/fsmonitor.c b/fsmonitor.c index 1f4aa1b150..0477500b39 100644 --- a/fsmonitor.c +++ b/fsmonitor.c @@ -55,7 +55,8 @@ int read_fsmonitor_extension(struct index_state *istate, const void *data, } istate->fsmonitor_dirty = fsmonitor_dirty; - if (istate->fsmonitor_dirty->bit_size > istate->cache_nr) + if (!istate->split_index && + istate->fsmonitor_dirty->bit_size > istate->cache_nr) BUG("fsmonitor_dirty has more entries than the index (%"PRIuMAX" > %u)", (uintmax_t)istate->fsmonitor_dirty->bit_size, istate->cache_nr); @@ -83,7 +84,8 @@ void write_fsmonitor_extension(struct strbuf *sb, struct index_state *istate) uint32_t ewah_size = 0; int fixup = 0; - if (istate->fsmonitor_dirty->bit_size > istate->cache_nr) + if (!istate->split_index && + istate->fsmonitor_dirty->bit_size > istate->cache_nr) BUG("fsmonitor_dirty has more entries than the index (%"PRIuMAX" > %u)", (uintmax_t)istate->fsmonitor_dirty->bit_size, istate->cache_nr);
This looks good to me. On Tue, Nov 12, 2019 at 5:30 PM Junio C Hamano <gitster@pobox.com> wrote: > > Kevin Willford <Kevin.Willford@microsoft.com> writes: > > > I agree. The only 2 places that excluding the split-index make sense are in > > read_fsmonitor_extension and write_fsmonitor_extension because the > > index_state that is being passing into those methods could be the delta index > > in which case the number of entries for the fsmonitor bitmap would almost > > always be more and cause the BUG to be hit which it should not be. > > Thanks. Here is what I came up with to tie the loose ends of this > thread. > > -- >8 -- > From: Junio C Hamano <gitster@pobox.com> > Subject: [PATCH] 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> > --- > fsmonitor.c | 6 ++++-- > 1 file changed, 4 insertions(+), 2 deletions(-) > > diff --git a/fsmonitor.c b/fsmonitor.c > index 1f4aa1b150..0477500b39 100644 > --- a/fsmonitor.c > +++ b/fsmonitor.c > @@ -55,7 +55,8 @@ int read_fsmonitor_extension(struct index_state *istate, const void *data, > } > istate->fsmonitor_dirty = fsmonitor_dirty; > > - if (istate->fsmonitor_dirty->bit_size > istate->cache_nr) > + if (!istate->split_index && > + istate->fsmonitor_dirty->bit_size > istate->cache_nr) > BUG("fsmonitor_dirty has more entries than the index (%"PRIuMAX" > %u)", > (uintmax_t)istate->fsmonitor_dirty->bit_size, istate->cache_nr); > > @@ -83,7 +84,8 @@ void write_fsmonitor_extension(struct strbuf *sb, struct index_state *istate) > uint32_t ewah_size = 0; > int fixup = 0; > > - if (istate->fsmonitor_dirty->bit_size > istate->cache_nr) > + if (!istate->split_index && > + istate->fsmonitor_dirty->bit_size > istate->cache_nr) > BUG("fsmonitor_dirty has more entries than the index (%"PRIuMAX" > %u)", > (uintmax_t)istate->fsmonitor_dirty->bit_size, istate->cache_nr); > > -- > 2.24.0-346-gee0de6d492 >
On 11/12/19 5:30 PM, Junio C Hamano wrote: > Thanks. Here is what I came up with to tie the loose ends of this > thread. > > -- >8 -- > From: Junio C Hamano <gitster@pobox.com> > Subject: [PATCH] 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> > --- > fsmonitor.c | 6 ++++-- > 1 file changed, 4 insertions(+), 2 deletions(-) > > diff --git a/fsmonitor.c b/fsmonitor.c > index 1f4aa1b150..0477500b39 100644 > --- a/fsmonitor.c > +++ b/fsmonitor.c > @@ -55,7 +55,8 @@ int read_fsmonitor_extension(struct index_state *istate, const void *data, > } > istate->fsmonitor_dirty = fsmonitor_dirty; > > - if (istate->fsmonitor_dirty->bit_size > istate->cache_nr) > + if (!istate->split_index && > + istate->fsmonitor_dirty->bit_size > istate->cache_nr) > BUG("fsmonitor_dirty has more entries than the index (%"PRIuMAX" > %u)", > (uintmax_t)istate->fsmonitor_dirty->bit_size, istate->cache_nr); > > @@ -83,7 +84,8 @@ void write_fsmonitor_extension(struct strbuf *sb, struct index_state *istate) > uint32_t ewah_size = 0; > int fixup = 0; > > - if (istate->fsmonitor_dirty->bit_size > istate->cache_nr) > + if (!istate->split_index && > + istate->fsmonitor_dirty->bit_size > istate->cache_nr) > BUG("fsmonitor_dirty has more entries than the index (%"PRIuMAX" > %u)", > (uintmax_t)istate->fsmonitor_dirty->bit_size, istate->cache_nr); > > This looks good to me. Thanks, William
William Baker <williamtbakeremail@gmail.com> writes: > On 11/12/19 5:30 PM, Junio C Hamano wrote: >> Thanks. Here is what I came up with to tie the loose ends of this >> thread. >> ... > > This looks good to me. Thanks.
The checks added in 3444ec2 to ensure that the fsmonitor_dirty bitmap does not have more bits than the index do not play well with the split index. git update-index --fsmonitor --split-index calls write_locked_index which calls write_shared_index as well as write_split_index. The first call fills up the fsmonitor_dirty bitmap, and the second modifies the index such that istate->cache_nr is zero and this assert is hit. The test written does reproduce the error, but only flakily. There is limited difference with GIT_TEST_FSMONITOR=fsmonitor-all or GIT_TEST_FSMONITOR=fsmonitor-watchman, so the flakiness might come from somewhere else, which I haven't tracked down. The test also requires checkout of a new branch, and checking out back to master. It's clear that the index gets into some poor state through these operations, and there is a deeper bug somewhere. At the very least, this patch mitigates an over-eager check for split index users while maintaining good invariants for the standard case. Also, I haven't been able to reproduce this with "standard" user commands, like status/checkout/stash, so the blast radius seems limited. Helped-by: Kevin Willford kewillf@microsoft.com [kewillf@microsoft.com] Helped-by: Junio C Hamano gitster@pobox.com [gitster@pobox.com] Signed-off-by: Utsav Shah utsav@dropbox.com [utsav@dropbox.com] Utsav Shah (1): fsmonitor: skip sanity check if the index is split fsmonitor.c | 8 ++++---- t/t7519-status-fsmonitor.sh | 23 +++++++++++++++++++++++ 2 files changed, 27 insertions(+), 4 deletions(-) base-commit: 566a1439f6f56c2171b8853ddbca0ad3f5098770 Published-As: https://github.com/gitgitgadget/git/releases/tag/pr-458%2FUtsav2%2Fsplit-fix-v1 Fetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-458/Utsav2/split-fix-v1 Pull-Request: https://github.com/gitgitgadget/git/pull/458