Re: git-rebase skips automatically no more needed commits

[Martin von Zweigbergk <martin.von.zweigbergk@gmail.com>]

Hi Ram and Thomas,

On Sat, 24 Sep 2011, Ramkumar Ramachandra wrote:

> Martin von Zweigbergk writes:
> > [...] We also want it to
> > work with --root, so we can not use git-cherry.

I think I was confused here; git-cherry should work just fine. Simply
leaving out the limit, or setting it to $onto, makes the walk go all
the way to the roots. After thinking a bit more about this, I'm
instead wondering what the purpose of the --root flag to git-rebase
is. Thomas introduced it in 190f532 (rebase: learn to rebase root
commit, 2009-01-05).

If I understand correctly, it 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. In Thomas's patch,
git-rebase started passing $onto..$orig_head instead of
$upstream..$orig_head to git-format-patch. It also started passing
--root to git-format-patch, but that was made unneccessary a few days
later in 68c2ec7 (format-patch: show patch text for the root commit,
2009-01-10).

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 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)?

Martin