git/list[1] front-page[2] threads[3] people[4] search[5] about
 

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

From
Steven Noonan <steven@uplinklabs.net>
Date
Dec 18, 2009, 04:26 UTC
Message-ID
<f488382f0912172026ye9950c9sd4f505d8db1e47d1@mail.gmail.com>
In-Reply-To
<alpine.LFD.2.00.0912172255500.23173@xanadu.home>
On Thu, Dec 17, 2009 at 7:57 PM, Nicolas Pitre <nico@fluxnic.net> wrote:
Show 45 quoted lines
> On Thu, 17 Dec 2009, Steven Noonan wrote:
>
>> On Thu, Dec 17, 2009 at 7:33 PM, Nicolas Pitre <nico@fluxnic.net> wrote:
>> > On Thu, 17 Dec 2009, Eric Paris wrote:
>> >
>> >> 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.
>
Ahh. That makes sense. I should really read up on alternates then.
- Steven
Previous: Nicolas PitreNext: Eric Paris
Message 29 of 30 in “git-reflog 70 minutes at 100% cpu and counting”
  1. Eric ParisDec 14, 2009
  2. Sverre RabbelierDec 14, 2009
  3. Jeff KingDec 14, 2009
  4. Eric ParisDec 14, 2009
  5. Jeff KingDec 14, 2009
  6. Eric ParisDec 14, 2009
  7. Sverre RabbelierDec 14, 2009
  8. Nicolas PitreDec 15, 2009
  9. Jeff KingDec 14, 2009
  10. Nicolas PitreDec 15, 2009
  11. Junio C HamanoDec 15, 2009
  12. Nicolas PitreDec 15, 2009
  13. Eric ParisDec 15, 2009
  14. Nicolas PitreDec 15, 2009
  15. Jeff KingDec 15, 2009
  16. Nicolas PitreDec 15, 2009
  17. Eric ParisDec 15, 2009
  18. Nicolas PitreDec 16, 2009
  19. Eric ParisDec 16, 2009
  20. Eric ParisDec 16, 2009
  21. Nicolas PitreDec 16, 2009
  22. Eric ParisDec 16, 2009
  23. Nicolas PitreDec 17, 2009
  24. Eric ParisDec 17, 2009
  25. Nicolas PitreDec 18, 2009
  26. Steven NoonanDec 18, 2009
  27. Eric ParisDec 18, 2009
  28. Nicolas PitreDec 18, 2009
  29. Steven NoonanDec 18, 2009
  30. Eric ParisDec 18, 2009

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.