Junio C Hamano <gitster@xxxxxxxxx> writes: > > Before concluding so, we may want to double check how Bloom filters > are built on case insensitive systems, though. If we normalize the > string by downcasing before murmuring the string, the resulting > Bloom filter may have more false positives for those who want to > (ab)use it to optimize case sensitive queries (without affecting > correctness), but case insensitive queries would be helped. I do > not think we support (or want to support) a repository that spans > across two filesystems with different case sensitivity, so those who > worked on our changed-path Bloom filter subsystem may have already > placed such an optimization, based on the case sensitivity recorded > in the repository (core.ignorecase). I understand. I should check whether commit graph file's change path bloom filter is case sensitive. If the change path bloom filter is case insensitive, we could optimize PATHSPEC_ICASE as well. > > Updating a patch with a fix to obvious known problems is good. > > Extending the scope of the series should be left out for a new > separate commit. It may even be a better idea to hold it while > the current set of patches are still being polished, and then sent > out as a new series after the dust settles (even if you internally > developed that part as a direct extension to the current effort). Got it. So for now I should just polish this current patch. Thanks, Lidong
