Am 18.06.20 um 22:31 schrieb René Scharfe:
> Am 15.06.20 um 22:14 schrieb SZEDER Gábor via GitGitGadget:
>> --- a/revision.c
>> +++ b/revision.c
>> @@ -670,9 +670,10 @@ static void prepare_to_use_bloom_filter(struct rev_info *revs)
>> {
>> struct pathspec_item *pi;
>> char *path_alloc = NULL;
>> - const char *path;
>> + const char *path, *p;
>> int last_index;
>> - int len;
>> + size_t len;
>> + int path_component_nr = 0, j;
>>
>> if (!revs->commits)
>> return;
>> @@ -705,8 +706,22 @@ static void prepare_to_use_bloom_filter(struct rev_info *revs)
>>
>> len = strlen(path);
>>
>> - revs->bloom_key = xmalloc(sizeof(struct bloom_key));
>> - fill_bloom_key(path, len, revs->bloom_key, revs->bloom_filter_settings);
>> + p = path;
>> + do {
>> + p = strchrnul(p + 1, '/');
>> + path_component_nr++;
>> + } while (p - path < len);
> And shouldn't we use is_dir_sep() or find_last_dir_sep() instead of
> hard-coding a slash?
Not necessarily. Paths should be normalized to use one specific
separator, probably slash, both when building and querying the Bloom
filter. Otherwise a filter that knows e.g. "foo/bar" could confidently
claim that "foo\bar" does not match. If this is done in a previous
step then using a literal slash here would be correct.
René
