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

Re: git-rebase skips automatically no more needed commits

From
Martin von Zweigbergk <martin.von.zweigbergk@gmail.com>
Date
Sep 8, 2011, 13:14 UTC
Message-ID
<alpine.DEB.2.00.1109080753460.12564@debian>
In-Reply-To
<CAC9WiBjMUg3SUOP9AJw6qCKrGVLs6Qy_O2fQa_SHX30NkjAEdw@mail.gmail.com>
On Thu, 8 Sep 2011, Francis Moreau wrote:
Show 10 quoted lines
> On Wed, Sep 7, 2011 at 6:29 PM, Junio C Hamano <gitster@pobox.com> wrote:
> > Francis Moreau <francis.moro@gmail.com> writes:
> >
> >> If I start the rebase process with : "git rebase -i -p master foo"
> >> then the filtering is happening. Here 'foo' has been created with
> >> v2.6.39 tag as start point and contains some patches cherry-picked
> >> from the upstream.
> >>
> >> However if I call git-rebase this way: "git rebase -i -p --onto master
> >> v2.6.39 foo", then it seems that no filtering is done.

Patches that are in both sides of v2.6.39...foo will be filtered, but as Junio said, what is in master is not considered. In your case, since foo was created from the tag, there should of course be no commits in foo..v2.6.39.

> I'm using "git rebase --onto A B C" because I want to simplify git's
> work.

What work? Calculating mege-base and patch-ids? But that's exactly what you said you don't want to avoid, no?

> I know that any commits between A..B are already in A history
Did you mean "B..A" here?
> and I'm not interested in rebasing them anyways.

They wouldn't be rebased by running "git rebase A C" either... Maybe I'm misunderstanding something.

> Hmm I dont understand why "rebase --onto A B C" wouldn't try to find
> the merge base between A and B. If it doesn't (which is quite uncommon
> I guess) then don't do the filtering as we're currently doing but if
> there's a merge base (common case) then do the filtering.

It could do that. I think that's what Junio meant by "justifiable--- I dunno". In your case, though, it seems like "git rebase master foo" would do exactly what you want.

Somewhat related, I think "git rebase --onto A B C" should NOT filter out patches that also appear both sides of "B...C", because when "--onto" is used, "B" is only used as a way to calculate the merge-base. I think it would make more sense to filter out from appears in both "B..C" what also appears in "C..A". This has been on my todo list for way too long. Some day I'll send out a patch for it and we'll see what others think.

Martin
Previous: Francis MoreauNext: Martin von Zweigbergk
Message 7 of 19 in “git-rebase skips automatically no more needed commits”
  1. Francis MoreauSep 6, 2011
  2. Junio C HamanoSep 6, 2011
  3. Francis MoreauSep 6, 2011
  4. Michael J GruberSep 7, 2011
  5. Junio C HamanoSep 7, 2011
  6. Francis MoreauSep 8, 2011
  7. Martin von ZweigbergkSep 8, 2011
  8. Martin von ZweigbergkSep 9, 2011
  9. Francis MoreauSep 9, 2011
  10. Martin von ZweigbergkSep 9, 2011
  11. Francis MoreauSep 9, 2011
  12. Martin von ZweigbergkSep 15, 2011
  13. Junio C HamanoSep 15, 2011
  14. Martin von ZweigbergkSep 16, 2011
  15. Martin von ZweigbergkSep 20, 2011
  16. Ramkumar RamachandraSep 24, 2011
  17. Martin von ZweigbergkSep 25, 2011
  18. Thomas RastSep 26, 2011
  19. Martin von ZweigbergkSep 28, 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.