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