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
> 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 ;-)
> 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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html