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

best practices against long git rebase times?

From
Andreas Krey <a.krey@gmx.de>
Date
Dec 4, 2015, 15:05 UTC
Message-ID
<20151204150546.GA17210@inner.h.apk.li>
Hi all,
our workflow is pretty rebase-free for diverse reasons yet.

One obstacle now appearing is that rebases simply take very long - once you might want to do a rebase there are several hundred commits on the remote branch, and our tree isn't small either.

This produces rebase times in the minute range. I suppose this is because rebase tries to see if there are new commits in the destination branch that are identical to one of the local commits, to be able to skip them. (I didn't try to verify this hypothesis.)

What can we do to make this faster?
Andreas
-- 
"Totally trivial. Famous last words."
From: Linus Torvalds <torvalds@*.org>
Date: Fri, 22 Jan 2010 07:29:21 -0800
Next: John Keeping
Message 1 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.