Re: Why can't git-rebase back up?

[linux@horizon.com]

> The one in "next" has a topic branch change which lets you say:
> 
>	$ git rebase --onto v2.6.16-rc2 v2.6.16-rc3 build
>
> which is a shorthand for
>
>	$ git checkout build
>	$ git rebase --onto v2.6.16-rc2 v2.6.16-rc3
>
> That is, tear out my changes that forked from the development
> trail that led to v2.6.16-rc3, and graft them on top of
> v2.6.16-rc2.

Ah, exactly what I was looking for!
However, why did you decide to make the *destination* the option?

Just giving a naive user's perspective, the argument to git-rebase
is the *destination*, and it "magically" figures out the source.

It would seem more natural to me to have an option to explicltly
specify the "from" and leave the positional argument as the "to".

That also lets you do something about the rebasing-a-merged-branch
problem.  If you have:
      g-->h-->i-->j topic
     /       /
a-->b-->c-->d-->e-->f master

Then I'd expect "git-rebase master topic" to fail with
an error message like:

	Error: "topic" and "master" do not have a unique common
		ancestor.  Possible common ancestors:
		b (master~4)
		d (master~2)
	Rebasing a branch with merges is generally not recommended,
	but if you want to do it, you need to specify where to cut
	off the branch to move.  You probably want one of the above.

And you have to use "git-rebase --from b master" or --from d.
H'm... is that unique?  What if you have a bizarre merge pattern
line


     k--->l---->m
    /            \
    | g-->h-->i-->j topic
    |/        
a-->b-->c-->d-->e-->f master

or 

      g-->h-->i-->j topic
     /       /
a-->b---------->c-->d master

is "--from b" well-defined?  I'll have to play with the existing
code to see what it does.