Re: Itches with the current rev spec

From: Junio C Hamano <gitster@pobox.com>
Date: Apr 26, 2013, 17:49 UTC
Message-ID: <7v7gjpxjw0.fsf@alter.siamese.dyndns.org>
In-Reply-To: <517A3E47.6010606@viscovery.net>

Johannes Sixt <j.sixt@viscovery.net> writes:

Show 9 quoted lines

> 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 catch up.

But the above is orthogonal to the syntax "../..." issue.

[Footnote]

*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.