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

Re: best practices against long git rebase times?

From
Andreas Krey <a.krey@gmx.de>
Date
Dec 6, 2015, 16:43 UTC
Message-ID
<20151206164345.GH22288@inner.h.apk.li>
In-Reply-To
<20151204153103.GP18913@serenity.lan>

On Fri, 04 Dec 2015 15:31:03 +0000, John Keeping wrote: ...

> I'm pretty sure that you're right and the cherry-pick analysis is where
> the time is spent.
But I'm pretty surprised as to the amount of CPU time that goes there.

I'm now rebasing a single commit with a single blank line added, and for 3000 new commits to rebase over (with 64 MByte of git log - for them) it takes twelve minutes, or about for commits per second, and all user CPU, no I/O. It's pretty linear in number of commits, too.

Andreas
-- 
"Totally trivial. Famous last words."
From: Linus Torvalds <torvalds@*.org>
Date: Fri, 22 Jan 2010 07:29:21 -0800
Previous: John KeepingNext: Jeff King
Message 3 of 13 in “best practices against long git rebase times?”
  1. Andreas KreyDec 4, 2015
  2. John KeepingDec 4, 2015
  3. Andreas KreyDec 6, 2015
  4. Jeff KingDec 7, 2015
  5. Junio C HamanoDec 7, 2015
  6. Jeff KingDec 7, 2015
  7. Junio C HamanoDec 8, 2015
  8. Christian CouderDec 8, 2015
  9. demerphqDec 4, 2015
  10. John KeepingDec 4, 2015
  11. demerphqDec 4, 2015
  12. Stefan BellerDec 4, 2015
  13. Andreas KreyDec 6, 2015

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.