Ramkumar Ramachandra <[email protected]> writes:
> Junio C Hamano wrote:
>> 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).
>> 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".
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
