Re: Itches with the current rev spec

[Junio C Hamano <gitster@pobox.com>]

Felipe Contreras <felipe.contreras@gmail.com> writes:

> I don't know what 'git rebase master' does, but I would expect 'git
> rebase --onto=master' to do the same thing. Then, if 'git rebase
> --onto=next master..topic' makes sense, so should 'git rebase next
> master..topic'.
>
> Moreover, it often annoys me that 'git rebase master' does exactly
> what I want, but 'git rebase --onto=master previous' doesn't find the
> commits that are already into 'master'. One would expect the more
> defined version to work better, but it doesn't =/

That all stems from the fact that rebase (not -i variant) predates
these nice A..B, A...B, and $(merge-base A B) concepts have been
ingrained in the user's mindset as the primary UI language of Git.

 - The UI language of "rebase origin" comes more from the "workflow"
   school.  "I have built on 'origin'; I want to catch up with its
   current state".  To support that workflow, 'origin' is the only
   thing you need to say, and "rebase origin" matches that nicely.
   If you then add "By the way, that statement expresses my wish for
   the 'topic' branch, not my current one", you get "rebase origin
   topic".

 - If the UI language for "rebase" were designed following the
   "composition using common elements like ranges and revisions"
   school, it would have started from "rebase --onto=X A..B".

Back then, we did not know which principle to design the UI language
would prevail, but we needed something that works to support the end
users.  So "git log" spoke "A..B" but "git rebase" took "origin".

Over time, the "composition" school prevailed and these days we see
many commands accept and act on revision ranges or discrete
revisions.

The same thing happened to format-patch, whose original syntax was

    format-patch origin

which is still accepted, but we have adjusted it to understand the
more prevalent

    format-patch origin..

because it is far more understandable if you know other commands
that are based on "composition" UI language.  That adjustment
started making sense after it has become clear that "composition"
school of UI language is the way forward.

It's just that "rebase" is waiting for the same kind of adjustment.

Hint, hint.