Re: [PATCH v2 05/10] cache-tree: implement cache_tree_find_path()
- From
Derrick Stolee <derrickstolee@github.com>
- Date
- May 20, 2022, 18:13 UTC
- Message-ID
- <9a89398a-c5ec-d386-d554-a077fefcd46b@github.com>
- In-Reply-To
- <xmqqczg9mg8s.fsf@gitster.g>
On 5/19/2022 4:14 PM, Junio C Hamano wrote:
Show 28 quoted lines
> "Derrick Stolee via GitGitGadget" <gitgitgadget@gmail.com> writes:
>
>> +struct cache_tree *cache_tree_find_path(struct cache_tree *it, const char *path)
>> +{
>> + const char *slash;
>> + int namelen;
>> + struct cache_tree_sub *down;
>> +
>> + if (!it)
>> + return NULL;
>> + slash = strchrnul(path, '/');
>> + namelen = slash - path;
>> + it->entry_count = -1;
>> + if (!*slash) {
>> + int pos;
>> + pos = cache_tree_subtree_pos(it, path, namelen);
>> + if (0 <= pos)
>> + return it->down[pos]->cache_tree;
>> + return NULL;
>> + }
>> + down = find_subtree(it, path, namelen, 0);
>> + if (down)
>> + return cache_tree_find_path(down->cache_tree, slash + 1);
>> + return NULL;
>> +}
>
> The tail recursion (and the one in the orginal) may want to be
> trivially converted to iteration with "goto".Good idea!
> It is somewhat surprising that we didn't have any external interface > to expose a sub-part of the cache_tree at all so far. It may be > because the API was so well designed that the abstraction did not > have to be exposed. I dunno.
I think the abstraction definitely fit the shape of its consumers pretty perfectly. I wonder if having a method like this will make us think of new ways to use the cache tree for other things.
Thanks, -Stolee