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
>>> 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.)


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

Reply via email to