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
1345
09:12 ajb@sloy/x86_64 [work.git] >git for-each-ref | grep "refs/tags"
| grep -v "commit" | wc -l
66
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
