Re: [PATCH 3/3] rebase: use peel_committish() where appropriate

Ramkumar Ramachandra [off-list ref] writes:

Junio C Hamano wrote:

quoted

You can also specify the commit at the end of the history to be
rebased (very useful while trial runs to see where a series should
apply):

    git rebase foo ":/Add B"

This is already handled properly because it first gets turned into
an object name $orig_head and then we use it (without ^0) to update
the ORIG_HEAD.

Correct, but what sense does it make unless <branch> is a ref to update?

It often is necessary, after applying a patch series that was
prepared against commit that is unnecessarily new (e.g. a bugfix
that should apply to 'maint' prepared against 'next'), to see if the
result rebases on older codebase.  Giving a commit (not branch) to
the command to force rebasing the commit on a detached HEAD is a
very handy technique to do so without damaging the original branch.

    $ git checkout mater^0
    $ git am -s mbox
    Applying A
    Applying B
    Applying C
    $ git rebase --onto maint master ":/B"

would see if the earlier two commits that are pure bugfix cleanly
applies to 'maint' (and then I can rebuild the topic by forking a
branch from 'maint', queue A and B, and if C is not needed for that
fix, fork another from that point, possibly merge 'master' to it and
then queue C).

quoted

What would happen when you are given "--onto :/f...o" is somewhat
interesting, but that may be a separate topic, I think.  At that
point, it is probably in the realm of "don't do it then" ;-)

The utility of this very series can be questioned.  I've rarely wanted
to use the :/fommery with rebase, so this mostly an exercise in
"theoretical correctness" (something I usually stay away from).

We are saying the same thing: "don't do it then".