On Mon, Jun 13, 2016 at 07:24:51AM +0700, Duy Nguyen wrote:
> >> - git fsck --full
> >> - git repack -Adl -b --pack-kept-objects
> >> - git pack-refs --all
> >> - git prune
> >>
> >> The reason it's split into repack + prune instead of just gc is because
> >> we use alternates to save on disk
On Jun 12, 2016, at 4:13 PM, Jeff King wrote:
>
>At GitHub we actually have a patch to `repack` that keeps all
>objects, reachable or not, in the pack, and use it for all of our
>automated maintenance. Since we don't drop objects at all, we can't
>ever have such a
On Mon, Jun 13, 2016 at 5:13 AM, Jeff King wrote:
> On Sun, Jun 12, 2016 at 05:54:36PM -0400, Konstantin Ryabitsev wrote:
>
>> > git gc --prune=now
>>
>> You are correct, this solves the problem, however I'm curious. The usual
>> maintenance for these repositories is a regular
On Sun, Jun 12, 2016 at 05:54:36PM -0400, Konstantin Ryabitsev wrote:
> > git gc --prune=now
>
> You are correct, this solves the problem, however I'm curious. The usual
> maintenance for these repositories is a regular run of:
>
> - git fsck --full
> - git repack -Adl -b --pack-kept-objects
On Sun, Jun 12, 2016 at 05:38:04PM -0400, Jeff King wrote:
> > - When attempting to repack, creates millions of files and eventually
> > eats up all available disk space
>
> That means these objects fall into the unreachable category. Git will
> prune unreachable loose objects after a grace
On Sun, Jun 12, 2016 at 05:25:14PM -0400, Konstantin Ryabitsev wrote:
> Hello:
>
> I have a problematic repository that:
>
> - Takes up 9GB on disk
> - Passes 'git fsck --full' with no errors
> - When cloned with --mirror, takes up 38M on the target system
Cloning will only copy the objects
Hello:
I have a problematic repository that:
- Takes up 9GB on disk
- Passes 'git fsck --full' with no errors
- When cloned with --mirror, takes up 38M on the target system
- When attempting to repack, creates millions of files and eventually
eats up all available disk space
Repacking the
7 matches
Mail list logo