Marc Branchaud <mbranch...@xiplink.com> writes:
> On 12-08-10 04:09 PM, Junio C Hamano wrote:
>> Felix Natter <fnat...@gmx.net> writes:
>>> I have a few questions about this:
>>>> As I am coming from "large depth is harmful" school, I would
>>>> - "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.
>> And you can add another file next to them
>> 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.
> 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
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