On Mon, Mar 15, 2021 at 02:14:40PM +0100, Patrick Steinhardt wrote:
> Move processing of tags into its own function to make the logic easier
> to extend when we're going to implement filtering for tags. No change in
> behaviour is expected from this commit.
Makes sense. Even without extending the logic, it is nice to see the
symmetric with the tree/blob paths.
Although I think it's not quite symmetric in practice...
> +static void process_tag(struct traversal_context *ctx,
> + struct tag *tag,
> + struct strbuf *base,
> + const char *name)
> +{
> + tag->object.flags |= SEEN;
> + ctx->show_object(&tag->object, name, ctx->show_data);
> +}
I'm skeptical that "base" will ever be meaningful here (as it would be
for trees and blobs), because we are never recursing a tree to hit a
tag. We do later pass it to filter_object(), but I think it will always
be the empty string (we even assert(base->len == 0) in the caller).
So I am tempted to say it should not take a base parameter at all, and
later the call to filter_object() added to process_tag() should just
pass an empty string as the base. That would make it clear we do not
expect any kind of "base". That's mostly academic, but I think it also
makes clear that the "name" field is not something that should be
appended to the base (unlike trees and blobs, it is the name we got from
the top-level parsing, not a pathname).
-Peff
