Re: Itches with the current rev spec

Ramkumar Ramachandra <artagnon@gmail.com> writes:

I am not "looking at" anything. I was giving the historical background to explain how the current UI language came to be, but that was not to argue for keeping it to be the way it is, or even to justify that it is the right UI.

Very interesting.

That world view is broken, isn't it? Perhaps you forgot to consider symmetric differences, where left positives and right positives have to be treated differently. "diff A B" and "diff B A" mean very different things, for that matter. A line of thought that begins with "there is no ordering" may be a "brave proposal", perhaps, but it is not "fundamental principles".

If you do not like the word "range", read it as a DAG.

"rebase requires three: onto, list and a ref" (by the way, it is not refspec, which has a specific meaning) is trapped by the limitation of its current UI language that came from the "workflow" school and missing what the operation really means.

rebase takes a DAG with one negative commit, and replays it to form an isomorphic DAG on top of another commit. At the essential level, it takes two pieces of information, such a DAG and an "onto" commit.

But in the current UI, the way to specify these two things are by giving three commits, i.e. --onto=ONTO ONE_NEGATIVE ONE_POSITIVE. The positive is used to specify which ref to update.

It is not far-fetched to allow rebase to handle a history with two branches A and B that share the common initial part (i.e. ^X A B) and replay that history on top of an unrelated point in history Y to transform:

             o---o---Y
            /
    ---o---X---C---C---A---A---A (tip of branch A)
                    \
                     B---B---B (tip of branch B)

into

             o---o---Y---C'--C'--A'--A'--A' (updated tip of branch A)
            /         \
    ---o---X           B'--B'--B' (updated tip of branch B)

But the "rebase one branch on a new base" UI that came from the "workflow" school is unable to express such an operation. The pieces of information we are using in the above are:

 * Where the bottom of the DAG being replayed is (i.e. X);
 * What refs are the top of the DAG (i.e. A and B);
 * Where the new bottom of the replayed DAG (i.e. Y).

So if we are refining the rebase UI, while making sure we can later extend it, we shouldn't start from "onto, list and a ref". We should start from "a single onto, a single bottom, and one or more refs that define tops".

So what? Why do you even _need_ to mix up all positive revisions, some of which mean different things from others, into a single bag, only to later differenciate some as special (i.e. used as the onto commit) from the others (i.e. the tips in the DAG)? If something is special, you can say not just it is special and can say what it means by saying "this is where I want to replay the DAG on top".

A much larger issue is that the current setup_revisions() infrastructure does not let us express an operation that involves two or more DAGs. People sometimes wish to say an equivalent of

    git show $(git rev-list A..B) $(git rev-list C..D)

but obviously

    git show A..B C..D

is not the way to say it, and this limitation comes from it.