Subject: Re: [PATCH v4 04/13] path-walk: always emit directly-requested objects

From: Derrick Stolee <[email-masked]>
Date: Thu, 21 May 2026 19:00:39 -0400

On 5/19/26 7:22 PM, Taylor Blau wrote:
> On Wed, May 13, 2026 at 09:18:46PM +0000, Derrick Stolee via GitGitGadget wrote:
>> diff --git a/path-walk.c b/path-walk.c
>> index 6e426af433..05bfc1c114 100644
>> --- a/path-walk.c
>> +++ b/path-walk.c
>> @@ -248,6 +248,17 @@ static int add_tree_entries(struct path_walk_context *ctx,
>>   	return 0;
>>   }
>>
>> +/*
>> + * Paths starting with '/' (e.g., "/tags", "/tagged-blobs") hold objects that
>> + * were directly requested by 'pending' objects rather than discovered during
>> + * tree traversal.
>> + */
>> +static int path_is_for_direct_objects(const char *path)
>> +{
>> +	ASSERT(path);
>> +	return path[0] == '/';
>> +}
>> +
> 
> Hmm, I still find this a little brittle. I think that 'path' here is
> doing a number of jobs: it serves as a strmap key, it's visible to the
> caller, and now also a "direct object" marker.
> 
> Could we instead store this explicitly on the type_and_oid_list, e.g. a
> "direct" flag? I'm not sure whether that type has the right scope for
> this information. If not, I wonder if there is another way to store this
> information, since I worry that future callers may not know about this
> convention and end up changing the result of the path-walk depending on
> how they name their paths.

I don't find this as fragile as you do, because these "direct" paths
_need_ to start with '/' to avoid collisions with other paths that may
exist _and_ this meaning is internal to the data within the API. Callers
can't change this data, though they will see the paths themselves in the
callback function.

And as I mentioned before, this is a memory-efficient storage of this
indicator bit because it only consumes memory when it is "on" and the
vast majority of cases where it is "off" it doesn't take any extra
storage.

Thanks,
-Stolee