Re: git tag --contains now takes a long time

From: Junio C Hamano <gitster@pobox.com>
Date: Oct 17, 2015, 21:28 UTC
Message-ID: <xmqq1tctchgz.fsf@gitster.mtv.corp.google.com>
In-Reply-To: <CAOLa=ZTDd3MSmqXArtNz8i5n=uj2NEB6UPk2jSnEhUsAqbr7nQ@mail.gmail.com>

Karthik Nayak <karthik.188@gmail.com> writes:

Show 18 quoted lines

> So I did poke around a little. I think I missed this out on the
> original commit (b7cc53e92c806b73e14b03f60c17b7c29e52b4a4).
>
> diff --git a/builtin/tag.c b/builtin/tag.c
> index 977a18c..2c5a9f1 100644
> --- a/builtin/tag.c
> +++ b/builtin/tag.c
> @@ -49,6 +49,7 @@ static int list_tags(struct ref_filter *filter,
> struct ref_sorting *sorting)
>                 format = "%(refname:short)";
>
>         verify_ref_format(format);
> +       filter->with_commit_tag_algo = 1;
>         filter_refs(&array, filter, FILTER_REFS_TAGS);
>         ref_array_sort(sorting, &array);
> ...
>
> Could you Squash that in, Junio?

Do we have two implementations that are supposed to compute the same thing, and with the bit set to 1, the faster of these two is used? Is there a reason somebody may want to use the slower one? What difference other than performance does the choice of this bit makes, and why?

I think the answers to the above questions deserve to be in the log message (no, I do not think I can "squash it in", rewriting the commit that has already been merged to 'next' and 'master').

Thanks.