From: Junio C Hamano <junkio@cox.net>
Date: Sun, 07 May 2006 23:35:53 GMT
Subject: Re: Unresolved issues #2 (shallow clone again)
Message-ID: <7vveshif1i.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <46a038f90605071627i6a335f61lf5e35291bfbe340c@mail.gmail.com>

"Martin Langhoff" <martin.langhoff@gmail.com> writes:

> On 5/7/06, Sergey Vlasov <vsu@altlinux.ru> wrote:
>> For linux v2.6.16:
>>
>> 7,3M commits-b41b04a36afebdba3b70b74f419fc7d97249bd7f.pack
>>  24M commits_trees-8397f1c2a885527acd07e2caa8c95df626451493.pack
>>  97M full-c7b2747a674ff55cb4a59dabebe419f191e360df.pack
>
> With this pack arrangement, do you get any noticeable difference in
> walking commits? How about walking commits+trees with git-log <path> ?
>
> I wonder whether segregating packs by object type would make things better...

It shouldn't.  The existing packfile is designed to make "git
log" very efficient, by making it cheap to look only at the
commit message and ancestry information.

The objects are sorted first by type in the pack with the
existing code already, and commits come first.  Try this.

        git repack -a -d
        git show-index <.git/objects/pack/pack-*.idx |
        sort -n |
        while read offset objectname
        do
                git cat-file -t "$objectname"
        done