Felipe Contreras <felipe.contre...@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
> 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
- 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
The same thing happened to format-patch, whose original syntax was
which is still accepted, but we have adjusted it to understand the
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.
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