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

Idea for rebase strategy

From
Johannes Schindelin <johannes.schindelin@gmx.de>
Date
Nov 27, 2006, 00:15 UTC
Message-ID
<Pine.LNX.4.63.0611270108160.30004@wbgn013.biozentrum.uni-wuerzburg.de>
Hi,

an idea hit me today: maybe we can make rebase work nicely with merges after all. We could record the original branch point and the new branch point for rebases.

If this information is somehow accessible when doing a merge, git could check if the old branch point is reachable from the current HEAD, but not the new branch point, and if both are the case, rebase the changes since the old branch point on top of the new branch point before trying to merge.

Does this sound too far-fetched?

Ciao, Dscho

Next: Junio C Hamano
Message 1 of 5 in “Idea for rebase strategy”
  1. Johannes SchindelinNov 27, 2006
  2. Junio C HamanoNov 27, 2006
  3. Andy WhitcroftNov 27, 2006
  4. Junio C HamanoNov 27, 2006
  5. Johannes SchindelinNov 27, 2006

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.