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

Re: [BUG] rebase -p loses commits

From
Jeff King <peff@peff.net>
Date
May 17, 2011, 05:44 UTC
Message-ID
<20110517054432.GC10048@sigill.intra.peff.net>
In-Reply-To
<4DD1C277.9070605@sohovfx.com>
On Mon, May 16, 2011 at 08:33:59PM -0400, Andrew Wong wrote:
Show 15 quoted lines
> On 05/16/2011 04:36 PM, Junio C Hamano wrote:
> >    F---*  feature
> >   /   /
> >  B---M    master
> >
> >But what does it mean to rebase that on top of master, preserving merges
> >in the first place? You are already on top of 'master' and '*' itself
> >should be what you should get, no?  IOW, shouldn't you already be
> >up-to-date?
> Since preserve-merge uses the interactive-rebase, I think
> interactive-rebase should still pick the merge commit, which will
> then be consistent with what's happening if we rebase onto "F". So,
> without knowing whether "F" or "M" is the first-parent, I think
> interactive-rebase onto "F" and onto "M" should have the same effect.
> i.e. interactive-rebase picks the merge commit

Is it really the first-parentness here that is important to the asymmetry? I thought it was more the fact that "feature" has the merge, but "master" does not.

Therefore, "git rebase -p master feature" knows that there is nothing to do; we already contain all of "master".

But "git rebase -p feature master" sees that we have an extra commit in "feature" not in "master", and therefore we must attempt to rewrite on top of that merge commit. Of course, when we try to do so, there are no commits that are not already on "feature", so there is nothing to rewrite.

So the outcomes are the same, but the reasoning is different. And isn't that what happens with Junio's patch (I tried a simple test and it seemed to be)?

-Peff
Previous: Junio C HamanoNext: Andrew Wong
Message 7 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.