All of lore.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.com \
    --cc=git@vger.kernel.org \
    --cc=nico@fluxnic.net \
    --cc=peff@peff.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.