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

Re: git-rebase skips automatically no more needed commits

From
Thomas Rast <trast@student.ethz.ch>
Date
Sep 26, 2011, 09:10 UTC
Message-ID
<201109261110.59940.trast@student.ethz.ch>
In-Reply-To
<alpine.DEB.2.00.1109242148570.24369@debian>
Martin von Zweigbergk wrote:
> 
> If I understand correctly, [rebase --root] was introduced to solve
> exactly the same reason problem that made Francis start this thread
> -- to avoid re-applying patches that are already in $onto.

Not quite; I wrote it because at the time, there was no way to transplant git history onto a git-svn "make empty subdir" commit for later dcommitting. So the main point was really

Show 14 quoted lines
> After my patches (that are not yet ready) that calculate revisions as
> "git cherry $onto $orig_head $upstream", I don't think there should be
> any need for the --root flag. The only place the flag is checked now
> (in my current work tree, that is) is when deciding how to interpret
> the remaining arguments. Although I have not tried (temporarily)
> rewriting all the test cases from
> 
>   git rebase --root --onto upstream branch
> 
> to
> 
>   git rebase upstream branch
> 
> , I think it should work. What do you think, Thomas?

I still think it would be natural for a user to want a way to say "all the way back to the root commit". At least for me the "full" rebase invocation is

  git rebase --onto onto base branch

In that mindset it comes natural to replace 'base' with --root if you want to go all the way.

Maybe I don't trust rebase enough to do what I want ;-)
Show 5 quoted lines
> I saw that
> "--root" is also passed to the hook. Should that value be passed to
> the hook also when the old base is not explicitly a root (by "rebase
> --root"), but only implicitly so (by an $onto that is disjoint from
> $branch)?

I think I did it that way because if you use --root, the base/upstream argument is missing, and the hook needs to know that.

If the user specifies an upstream that is disjoint from the branch itself, the hook gets the upstream argument and can presumably work it out from there. So you could perhaps save the hook some trouble if you *know* that it's a disjoint rebase, but I wouldn't spend too much time on that.

-- 
Thomas Rast
trast@{inf,student}.ethz.ch
Previous: Martin von ZweigbergkNext: Martin von Zweigbergk
Message 18 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.