Re: git repack vs git gc --aggressive

[Marc Branchaud <mbranchaud@xiplink.com>]

On 12-08-10 04:09 PM, Junio C Hamano wrote:
> Felix Natter <fnatter@gmx.net> writes:
> 
>> I have a few questions about this:
>>
>>> As I am coming from "large depth is harmful" school, I would
>>> recommend
>>>
>>>  - "git repack -a -d -f" with large "--window" with reasonably short
>>>    "--depth" once, 
>>
>> So something like --depth=250 and --window=500? 
> 
> I would use more like --depth=16 or 32 in my local repositories.
> 
>>> and mark the result with .keep;
>>
>> I guess you refer to a toplevel '.keep' file.
> 
> Not at all.  And it is not documented, it seems X-<.
> 
> Typically you have a pair of files in .git/objects/pack, e.g.
> 
>   .git/objects/pack/pack-2e3e3b332b446278f9ff91c4f497bc6ed2626d00.idx
>   .git/objects/pack/pack-2e3e3b332b446278f9ff91c4f497bc6ed2626d00.pack
> 
> And you can add another file next to them
> 
>   .git/objects/pack/pack-2e3e3b332b446278f9ff91c4f497bc6ed2626d00.keep
> 
> to prevent the pack from getting repacked.  I think "git clone" does
> this for you after an initial import.

1.7.12.rc1 does not.

I even cloned from a repo with a few .keep files, but ended up with only one
big .pack file.

Maybe clone should preserve the packs it gets from the upstream repo?  For
example, our main repo has a 690MB pack file that's marked .keep, but the
clone just ends up with a single 725MB pack file.  Would our clones see
performance improvements if they that big 690MB pack separate from the others?

Perhaps the fact that clone creates a single pack file makes it impossible to
preserve the .keep packs from the upstream?

(I figure it's probably not a good idea for clone to .keep the single pack
file it creates.)

		M.