On 4/11/2020 5:40 PM, Junio C Hamano wrote: > "Derrick Stolee via GitGitGadget" <gitgitgadget@xxxxxxxxx> writes: > >> From: Derrick Stolee <dstolee@xxxxxxxxxxxxx> >> >> The changed-path Bloom filters work only when we can compute an >> explicit Bloom filter key in advance. When a pathspec is given >> that allows case-insensitive checks or wildcard matching, we >> must disable the Bloom filter performance checks. > > How often do we want to do case-insensitive path matching, I wonder. > > As somebody who never touches case-insensitive filesystem, I would > be a bad judge, and I would imagine that I would be looking for a > pathspec "[Mm]akefile" rather than ":(icase)makefile" myself if > there are projects that may have either/both, so I do not mind > disabling the bloom filter for case insensitivity myself. > > But if users may use icase pathspec very often, it may be worth > considering to build the bloom filter after downcasing the paths, > perhaps? Given that many projects extract their source code to a > case insensitive filesystem, I would imagine that downcasing paths > would map two originally different paths into the same thing only > rarely, if ever, so there may not be much downside to do so. This behavior could be extended later, and carefully. My initial thought was that the case check would happen on every commit. If the :(icase) check only happens at the walk tip(s), then we could compute a single Bloom key at the start. Thanks, -Stolee
