Junio C Hamano wrote:
> - 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".
I think you're looking at the whole issue backwards from the way I
look at it. Let's try to lay out some fundamental principles and
build a representations on top of that:
1. All rev specs (those specified in revisions.txt) either emit a
single positive/ negative (^) commit or multiple positive/ negative
commits (where the ordering does not matter).
2. Fundamentally, all commands require single/ multiple commits to
operate on. They might also require some additional information.
rebase requires three pieces of information: the commit onto which to
replay, a list of commits to replay, and a refspec to update once the
replaying is done.
log requires one piece of information: the list of commits.
diff requires two pieces of information: two commits to diff.
3. "Range" is not an inherent property of A..B or A...B. There are no
4. Every command is free to interpret positive and negative commits as
it sees fit. Since there is no ordering, it must never treat one
negative commit differently from another negative commit, or one
positive commit differently from another positive commit.
show takes a list of positive commits and shows all of them.
log will show all the commits reachable from positive commits, and
exclude all the commits reachable from negative commits. Here, the
"list of commits" are interpreted differently from the show case.
diff can either take two positive commits or one positive + one
negative commit. In the latter case, it swaps the arguments and
treats both as positive commits.
rebase can take one negative commit and one positive commit. The
commits reachable from the positive commit, but not from the negative
commit are replayed onto the negative commit. Now, we can use --onto=
to override the commit onto which to replay. But the fundamental
constraint remains: rebase _cannot_ make this --onto= parameter part
of the normal rev spec (we only have two types of commits: positive
and negative to which we can assign different meanings).
This, I think, is the way forward. In any command, forcing the user
to differentiate between the two commits only using argv and
argv is just horrible (diff with two positive commits is the only
necessary exception to this rule).
Further, what I think is of utmost importance is consistency.
Inventing loose mnemonics like in the diff case is the road to
insanity. All commands _must_ behave exactly the same way with all
the different rev specs (or error out when the particular rev spec
emits more commits than the command needs/ the wrong number of
What's more? I have a solution. A brand new revspec is the _only_
way to solve our problems without breaking consistency, or trading off
terseness [Who wants to do git rebase --onto master $(git merge-base
master topic)..topic every single time?]. I mentioned it on the other
thread, but didn't get feedback :(
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