public inbox for git@vger.kernel.org 
 help / color / mirror / Atom feed
From: Eric Paris <eparis@redhat•com>
To: Nicolas Pitre <nico@fluxnic•net>
Cc: Jeff King <peff@peff•net>, git@vger•kernel.org
Subject: Re: git-reflog 70 minutes at 100% cpu and counting
Date: Thu, 17 Dec 2009 11:29:29 -0500	[thread overview]
Message-ID: <1261067369.2868.10.camel@localhost> (raw)
In-Reply-To: <alpine.LFD.2.00.0912161841210.23173@xanadu.home>

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

> 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

  reply	other threads:[~2009-12-17 16:29 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-12-14 20:28 git-reflog 70 minutes at 100% cpu and counting Eric Paris
2009-12-14 20:41 ` Sverre Rabbelier
2009-12-14 21:11 ` Jeff King
2009-12-14 21:20   ` Eric Paris
2009-12-14 21:23     ` Jeff King
2009-12-14 21:56       ` Eric Paris
2009-12-14 22:03         ` Sverre Rabbelier
2009-12-15  0:29           ` Nicolas Pitre
2009-12-14 22:14         ` Jeff King
2009-12-15  0:26         ` Nicolas Pitre
2009-12-15  0:36           ` Junio C Hamano
2009-12-15  3:58             ` Nicolas Pitre
2009-12-15  2:11           ` Eric Paris
2009-12-15  3:44             ` Nicolas Pitre
2009-12-15  2:39     ` Jeff King
2009-12-15  3:50       ` Nicolas Pitre
2009-12-15  4:26         ` Eric Paris
2009-12-16  3:03           ` Nicolas Pitre
2009-12-16  3:31             ` Eric Paris
2009-12-16 13:41             ` Eric Paris
2009-12-16 21:06               ` Nicolas Pitre
2009-12-16 22:37                 ` Eric Paris
2009-12-17  5:38                   ` Nicolas Pitre
2009-12-17 16:29                     ` Eric Paris [this message]
2009-12-18  3:33                       ` Nicolas Pitre
2009-12-18  3:44                         ` Steven Noonan
2009-12-18  3:52                           ` Eric Paris
2009-12-18  3:57                           ` Nicolas Pitre
2009-12-18  4:26                             ` Steven Noonan
2009-12-18  3:55                         ` Eric Paris

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1261067369.2868.10.camel@localhost \
    --to=eparis@redhat$(echo .)com \
    --cc=git@vger$(echo .)kernel.org \
    --cc=nico@fluxnic$(echo .)net \
    --cc=peff@peff$(echo .)net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox