Re: Really slow 'git gc'

From: Linus Torvalds <torvalds@linux-foundation.org>
Date: Feb 19, 2009, 21:25 UTC
Message-ID: <alpine.LFD.2.00.0902191318310.21686@localhost.localdomain>
In-Reply-To: <7vr61uku2f.fsf@gitster.siamese.dyndns.org>

On Thu, 19 Feb 2009, Junio C Hamano wrote:

> 
> I think we can add a single bit to "struct packed_git" and in the middle
> of setup_revisions() perform the O(N**2) once, so that find_pack_entry()
> can check the bit without looping.

Yes. However, most users call find_pack_entry() with a NULL ignore_packed, so we'd still have to pass in that flag to say whether we should look at the bit or not.

However, the real issue (?) I think is that the whole "ignore_packed" logic is crazy. It's the wrong way around. The whole thing is broken.

Rather than marking which ones are "unpacked" and should be ignored, it should just look at the ones to keep. That's how the filesystem layout works and that's what "git repack" does anyway.

So I think we should just remove the whole "--unpacked=" thing, and instead replace it with a "--keep" flag - and then only finding things in the keep packs if we have a list of them.

That would (a) make the logic a whole lot easier to follow and (b) get rid of the scalability issue, since you're not really supposed to have more than one or two .keep files anyway (if that).

Nobody uses "--unpacked=xyzzy" by hand anyway. The only thing that generates those things is git-repack.sh, so this is not a compatibility issue, I suspect.

			Linus