Taylor Blau <me@xxxxxxxxxxxx> writes:
> Fix that by correctly assigning the value of 'revs->tag_objects' to the
> 'tmp_tags' field.
Makes sense. This breakage would make no difference in practice
right now, as {type}_objects members of the rev_info structure have
always been all flipped on together since their inception at
3c90f03d (Prepare git-rev-list for tracking tag objects too,
2005-06-29), so the original value of the tag_objects member is
always the same as that of the blob_objects member.
A possible alternative "fix" for this typo could be to unify these
{type}_objects members into a single .non_commit_objects member in
the rev_info structure; given that we (as far as I remember) never
utilized the "feature" that, say, we can ask only for trees but not
blobs for the past ~20 years, nobody knows if the apparent "support"
for that feature is subtly broken in multiple ways (and one of them
you just fixed with this patch) and the "feature" may not be worth
keeping.
But neverhteless, this is a correct thing to do unless we decide to
rip out the support for individual types. Will queue.
Thanks.
>
> Signed-off-by: Taylor Blau <me@xxxxxxxxxxxx>
> ---
> Noticed while I was looking for an example of this pattern somewhere in
> the codebase and was surprised when I found this typo ;-).
>
> pack-bitmap.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/pack-bitmap.c b/pack-bitmap.c
> index 4fa9dfc771..683f467051 100644
> --- a/pack-bitmap.c
> +++ b/pack-bitmap.c
> @@ -1270,7 +1270,7 @@ static struct bitmap *find_boundary_objects(struct bitmap_index *bitmap_git,
>
> tmp_blobs = revs->blob_objects;
> tmp_trees = revs->tree_objects;
> - tmp_tags = revs->blob_objects;
> + tmp_tags = revs->tag_objects;
> revs->blob_objects = 0;
> revs->tree_objects = 0;
> revs->tag_objects = 0;
>
> base-commit: 4083a6f05206077a50af7658bedc17a94c54607d
> --
> 2.47.0.237.gc601277f4c4
