Ramkumar Ramachandra <artagnon@xxxxxxxxx> writes:
>> - 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.
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.
> Let's try to lay out some fundamental principles and
Very interesting.
> 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.
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".
> constraint remains: rebase _cannot_ make this --onto= parameter part
> of the normal rev spec
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.
--
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