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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Karthik Nayak <karthik.188@xxxxxxxxx> writes:

> 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.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]