Re: Keeping unreachable objects in a separate pack instead of loose?

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

 



On Mon, 11 Jun 2012 17:14:14 -0400, Jeff King <peff@xxxxxxxx> wrote:
On Mon, Jun 11, 2012 at 10:44:39PM +0200, Hallvard Breien Furuseth wrote:

>OK, so that 4.5 is at least a respectable percentage of the total
>repo
>size. I suspect it may be worse for small repos in that sense, (...)

'git gc' gave a 3100% increase with my example:

    $ git clone --bare --branch linux-overhaul-20010122 \
        git://git.savannah.gnu.org/config.git
    $ cd config.git/
    $ git tag -d `git tag`; git branch -D master
    $ du -s objects
    624     objects
    $ git gc
    $ du -s objects
    19840   objects

Basically: Clone/fetch a repo, keep a small part of it, drop the
rest, and gc.  Gc explodes all the objects you no longer want.

I would argue that this is not a very interesting case in the first
place, since the right thing to do is use "clone --single-branch"[1] to
void transferring all of those objects in the first place.

Yeah, I just wanted a simple way to fetch a lot and drop most of
it, since that's what triggers the problem.  A simple use case
would be where you did a lot of work between cloing and pruning
most refs.  I described some actual use cases below the command.

But there are plenty of variant cases, where you are not just deleting
all of the refs, but rather doing some manipulation of the branches,
diffing them to make sure it is safe to drop some bits, running
filter-branch, etc. And it would be nice to make those cases more
efficient.

--
Hallvard
--
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]