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 "revision ranges". 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[0] and argv[1] 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 positive-negative commits). 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 majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html