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

Re: [PATCH] rebase -i -p: doesn't pick certain merge commits that are children of "upstream"

From
Stephen Haberman <stephen@exigencecorp.com>
Date
Jun 18, 2011, 15:17 UTC
Message-ID
<20110618101718.6ff03688@sh9>
In-Reply-To
<4DFC4863.2090803@sohovfx.com>
> In commit a4f25e3, we could already rebase B1 and squash F1 onto D1, 
> while reusing C1 and recreating the merge. That means we could
> already pass t3411.2if we adjusted the todo-list to account for the
> extra "pick C1" line.
You're right. I was wrong about that.
> Slightly off-topic, but I believe the branches will remain intact as
> long as the branch commits remain in the same topo-order relative to
> each other in the todo-list.
If in topo-order, yeah, I guess that is right.
> i.e. git will be confused if we try to move a commit from one branch
> into the other.

Right. If I do `rebase -i -p B1` and in the todo put C1 after F1, I get a fatal message that E1 cannot be cherry picked.

Given rebase-i-p's limited ability to reorder graphs, e.g. the error above, my understanding was that, when -p is used, only first-parent changes should be in the todo. This straight line, non-graph list does limit what the user can do, but, AFAIK, the benefit is that rebase-i-p can then actually handle any given reordering of the todo.

Letting C1 into the todo would mean having to explain to the user why some of their reorderings worked and others didn't. Or else making rebase-i-p smart enough to handle all cases. Which, IIRC, was something considered unlikely just given the fact that todo is flat and there isn't a way for the user to express topo reorderings. At the time, there was talk of another rewriting tool that would use marks and other hints to handle graphs and it was considered what, if anything, would eventually handle complex rewrites like this.

I think that Jeff's use case of rebase-i-p'ing C1, which is not on the first-parent list of commits, should be an error as it delves into territory (topo reordering) that rebase-i-p can't fully handle.

(If -p isn't used, just regular rebase, everything is being flattened, so there is no concern of topo reordering, so things are a lot simpler and C1 can/should be in the list.)

- Stephen
Previous: Andrew WongNext: Andrew Wong
Message 23 of 28 in “[BUG] rebase -p loses commits”
  1. Jeff KingMay 16, 2011
  2. Andrew WongMay 16, 2011
  3. Junio C HamanoMay 16, 2011
  4. Andrew WongMay 17, 2011
  5. Junio C HamanoMay 17, 2011
  6. Junio C HamanoMay 17, 2011
  7. Jeff KingMay 17, 2011
  8. Andrew WongMay 17, 2011
  9. Jeff KingMay 17, 2011
  10. [RFC] Interactive-rebase doesn't pick all children of "upstream"Andrew Wong, May 21, 2011
  11. [RFC] Interactive-rebase doesn't pick all children of "upstream"Andrew Wong, May 21, 2011
  12. Andrew WongMay 21, 2011
  13. Interactive-rebase doesn't pick all children of "upstream"Andrew Wong, Jun 5, 2011
  14. Johannes SixtJun 5, 2011
  15. Andrew WongJun 5, 2011
  16. rebase -i -p: doesn't pick certain merge commits that are children of "upstream"Andrew Wong, Jun 7, 2011
  17. rebase -i -p: doesn't pick certain merge commits that are children of "upstream"Andrew Wong, Jun 7, 2011
  18. Andrew WongJun 12, 2011
  19. Junio C HamanoJun 13, 2011
  20. Andrew WongJun 13, 2011
  21. Stephen HabermanJun 16, 2011
  22. Andrew WongJun 18, 2011
  23. Stephen HabermanJun 18, 2011
  24. Andrew WongJun 18, 2011
  25. Stephen HabermanJun 18, 2011
  26. rebase -i -p: include non-first-parent commits in todo listAndrew Wong, Jun 18, 2011
  27. Andrew WongJun 18, 2011
  28. Jeff KingMay 17, 2011

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.