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:
> >>
> >>> 41.58% git libcrypto.so.1.0.0 [.] sha1_block_data_order_ssse3
> >>> 33.62% git libz.so.1.2.3.4 [.] inflate_fast
> >>> 10.39% git libz.so.1.2.3.4 [.] adler32
> >>> 2.03% git [kernel.kallsyms] [k] clear_page_c
> >>
> >> Do you have any large blobs in the repo that are referenced directly by
> >> a tag?
> >
> > Most probably. I've certainly done a bunch of releases (which are tagged)
> > were
> > the last thing that was updated was an FPGA image.
> [...]
> >> git-describe should probably be fixed to avoid loading blobs, though I'm
> >> not sure off hand if we have any infrastructure to infer the type of a
> >> loose object without inflating it. (This could probably be added by
> >> inflating only the first block.) We do have this for packed objects, so
> >> at least for packed repos there's a speedup to be had.
> >
> > 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.
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.
--
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
