Re: git-reflog 70 minutes at 100% cpu and counting

On Thu, 17 Dec 2009, Steven Noonan wrote:

On Thu, Dec 17, 2009 at 7:33 PM, Nicolas Pitre [off-list ref] wrote:

quoted

On Thu, 17 Dec 2009, Eric Paris wrote:

quoted

This alone almost certainly tells me how I broke it.

For quite some time (a period of months) linux-next was broken and I had
to carry a patch to ACPI to make it boot.  I dropped that patch at the
head of my stgit trees in all of my repositories.  So I wouldn't be at
all surprised to learn that eventually kernel-2 found that object in
kernel-1.  Sometime when I dropped that patch from kernel-1 (because it
finally got fixed upstream) I can see how it broke.

But now that patch shouldn't be needed by any tree since I have long
since dropped it from the stgit stack.  So if we cleaned up all of the
useless objects in this tree I bet this object wouldn't be needed.  Not
exactly a situation that I'd expect git to be able to dig out of itself
thought.

I let the script I provided previously ran for a while.  And the commit
I found to contain the missing object belongs to
refs/patches/fsnotify/fsnotify-group-priorities.log.  So I simply
deleted that branch entirely and now the repack can proceed.  And with a
'git gc --aggressive' the 1.2GB repository shrank to a mere 5.2 MB.  :-)
Of course I didn't bring back all the reflogs though.  But I would
have expected a repository reduction of the same magnitude even with
them.

Are we talking about the same Linux kernel repository as before?

As before in this thread.

Because if so, that reduction in size doesn't make any sense to me.

Sure it does.

The smallest size I've seen for the Linux kernel repository (in the
past year) is 250MB.

Depends if you have an alternate repository from which you may borrow 
objects from, which was the case here.  In that context, 1.2 GB of disk 
space was completely insane.


Nicolas