On 30 May 2013 20:30, John Keeping <j...@keeping.me.uk> wrote:
> On Thu, May 30, 2013 at 06:21:55PM +0200, Thomas Rast wrote:
>> Alex Bennée <kernel-hac...@bennee.com> writes:
>> > On 30 May 2013 16:33, Thomas Rast <tr...@inf.ethz.ch> wrote:
>> >> Alex Bennée <kernel-hac...@bennee.com> writes:
> <snip>
>> > Will it be loading the blob for every commit it traverses or just ones 
>> > that hit
>> > a tag? Why does it need to load the blob at all? Surely the commit
>> > tree state doesn't
>> > need to be walked down?
>> No, my theory is that you tagged *the blobs*.  Git supports this.

Wait is this the difference between annotated and non-annotated tags?
I thought a non-annotated just acted like references to a particular
tree state?

> You can see if that is the case by doing something like this:
>     eval $(git for-each-ref --shell --format '
>         test $(git cat-file -t %(objectname)^{}) = commit ||
>         echo %(refname);')
> That will print out the name of any ref that doesn't point at a
> commit.

Hmm that didn't seem to work. But looking at the output by hand I
certainly have a mix of tags that are commits vs tags:

09:08 ajb@sloy/x86_64 [work.git] >git for-each-ref | grep "refs/tags"
| grep "commit" | wc -l
09:12 ajb@sloy/x86_64 [work.git] >git for-each-ref | grep "refs/tags"
| grep -v "commit" | wc -l

Unfortunately I can't just delete those tags as they do refer to known
releases which we obviously care about. If I delete the tags on my
local repo and test for a speed increase can I re-create them as
annotated tag objects?

Alex, homepage: http://www.bennee.com/~alex/
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to