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

From: Eric Paris <eparis@redhat.com>
Date: Dec 17, 2009, 16:29 UTC
Message-ID: <1261067369.2868.10.camel@localhost>
In-Reply-To: <alpine.LFD.2.00.0912161841210.23173@xanadu.home>

On Thu, 2009-12-17 at 00:38 -0500, Nicolas Pitre wrote:

Show 29 quoted lines

> Moving the reflog data aside (i.e. mv .git/logs .git/logs.bak) it seems 
> that d936ff8 is not referenced anymore.
> 
> I found the other one as follows:
> 
> First I tried
> 
> $ git rev-list --all --objects
> 
> This resulted in:
> 
> [...]
> 4f7911b0b0dbd187131a109cf00161a0c6a9d727 arch/x86
> ea868257c1eabc31e0ea7941efa42b543978b3fa arch/x86/kvm
> a0c11ead723956c667172a9f3fb6787684fe7ff5 arch/x86/kvm/paging_tmpl.h
> b556b6aad8b1aacfecb1dd4a56dbd389674687b5 arch/x86/kvm/x86.c
> 68a9733ae3315d7e2bfec2037dfeee4db8a6f6a1 drivers
> error: Could not read 29b6c2fb1390b4fd350a5ecc78f1156fc5d91e9f
> fatal: bad tree object 29b6c2fb1390b4fd350a5ecc78f1156fc5d91e9f
> 
> Because of the way objects are enumerated, we can be pretty sure that 
> the bad tree object is referenced by the tree object 68a9733a 
> corresponding to drivers/.  Let's verify that:
> 
> $ git ls-tree 68a9733a
> 100644 blob 00cf9553f74065291612b0971337f79995933a06    Kconfig
> 100644 blob c1bf41737936ab00be4a87563a0bb0638074785d    Makefile
> 040000 tree d4e847de9bf2450842936582ea7cc6778413825b    accessibility
> 040000 tree 29b6c2fb1390b4fd350a5ecc78f1156fc5d91e9f    acpi

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'm creating clean repos and going to do no work in my -alt    :)

Thanks everyone!

-Eric