Re: git repack vs git gc --aggressive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Marc Branchaud <mbranchaud@xxxxxxxxxxx> writes:

> On 12-08-10 04:09 PM, Junio C Hamano wrote:
>> Felix Natter <fnatter@xxxxxxx> 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.

Sorry, I misremembered.  It was removed at 1db4a75 (Remove
unnecessary pack-*.keep file after successful git-clone,
2008-07-08), so even when the sender gave you a crappy pack, you can
repack locally to correct it.

> Maybe clone should preserve the packs it gets from the upstream repo?

That was part of the intention of the code 1db4a75 removed.

> 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?

There is no "pack boundary" in the object transfer protocol.  What
comes out of the wire is a single stream of pack data, so the above
is not feasible without major surgery and backward incompatible
change.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]