Johannes Sixt <j.s...@viscovery.net> writes:
> Allow alternative spelling of
> git rebase -i master topic
> like this:
> git rebase -i master..topic
> (as always, the default for topic is HEAD).
I actually made this typo a few times in the past.
In a single-strand-of-pearls history, what rebase operates on is
clearly a _range_ with a defined linear order of commits, and
master..topic is a natural way to express it.
And rebase not just needs the range that defines the set of commits
to be replayed, but also needs the commit on top of which they are
replayed. It is natural to take ^master as that commit, and it is
useful when you are trying to catch up with that branch.
The reason you would use "rebase -i" is not for catching up [*1*],
so defaulting to replay onto ^master is not useful. You want the
command to replay on top of the stable same base, so that you can
compare the result with the previous version in order to verify.
Often, the fork-point with master is a good choice for that.
It is tempting to say that "rebase -i" and normal catch-up "rebase"
(e.g. "pull --rebase") should have designed to behave differently.
"git rebase -i master" perhaps should have made to rebase the
current work on top of the fork-point from master, not on top of it,
and require an explict --onto master if the user does want to also
But the above is orthogonal to the syntax "../..." issue.
*1* "rebase" and "rebase -i" already behave slightly differently
with respect to $onto" in that a catch-up rebase that is already up
to date notices the situation and turns into a no-op, but it does
not turn "rebase -i" into a no-op for this exact reason.
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html