Hi Johannes,
Johannes Schindelin <Johannes.Schindelin@xxxxxx> writes:
> Hi Sergey,
>
[...]
> In the parlance of your RFC v2, where you start with this history (which I
> translated into the left-to-right notation that is used in pretty much all
> of Git's own documentation about interactive rebases, which you apparently
> either did not read, or chose *not* to imitate, creating yet another
> unnecessary diversion):
>
>
> - B1
> \
> - B2 - M
First, it should rather be:
- B1
\
M
/
- B2
as RFC presents essentially symmetric approach and I'd like it to be
explicit. Representation in RFC simply saves some vertical
space:
M
/ \
B1 B2
Another reason to use it is that I liked to somehow indicate that this
is about abstract DAG representation of Git history, not to be confused
with some actual practical Git history. So that, for example, the reader
can't be tempted to even try to assume that M has been necessarily
created by "git merge" operation in the first place.
That said, I'm sorry if it upsets you. I'll stick to your preferred
notation below.
>
> You now insert U1 and U2 with trees identical to M:
>
> - B1 - U1
> \
> - B2 - U2 - M
- B1 - U1
\
UM
/
- B2 - U2
_YES_. You've slightly screwed RFC as UM is not M anymore, having
different parents, but otherwise it's still right.
> So U1 is essentially B2 cherry-picked on top of B1, and U2 is essentially
> B1 cherry-picked on top of B2.
_NO_. No any cherry-picking has been involved, and I see absolutely no
reason to pretend there has, except to intentionally make otherwise
simple thing look tricky.
U1 tree is still M tree, and U2 tree is still M tree, and UM tree is
still M tree. That's what actually matters from RFC POV.
> These U1/U2 commits are now to be cherry-picked on top of the rebased B1'
> and B2'. I spare you more diagrams, you get the idea.
_YES_. Exactly 2 cherry-picks.
> Now, the changes in U1/U2 *are* the changes of the merge parents, that's
> how they were constructed.
Either _YES_, or _NO_, depending on the exact meaning of the term "the
changes of the merge parents" you've used, but I suspect it's _NO_,
taking into account your further inferences.
The U1/U2 are constructed by simply duplicating the tree of the original
merge commit M and thus they represent the changes _to_ the merge
parents B1/B2 introduced by M, and not the changes "_of_ the merge
parents" B1/B2, provided the latter meant to have some relation to the
changes introduced by the merge parents B1/B2 themselves.
>
> Since they repeat what B1 and B2 are about,
_NO_, they do not repeat what B1 and B2 are about at all. They rather
represent what M is about. In other words, whatever B1 and B2 are about,
the RFC method doesn't care.
And as this is fundamental misinterpretation of the RFC on your side, it
starts to be big _NO_ from now on...
> and since B1'/B2' means they are rebased, and since U1'/U2' are *also*
> rebased, but independently...
>
> ... you essentially have to rebase *every parent's changes
> twice*.
_NO_. U1' is rebase of U1 (on top of B1'), and U2' is rebase of U2 (on
top of B2'). Each of U1/U2 is rebased only once.
> The answer "No" to this is... astonishing.
It's still _NO_, sorry.
In fact, I could have said _NO_ the first time you started to assign
some arbitrary "meaning" to the commits, as RFC is about somewhat formal
proof of the method, using already well-known operations on the DAG, and
to criticize the RFC, you need to either find and show a _formal_
mistake somewhere in the proof logic, or to show a use-case where it
fails, as you did for RFC v1. Assigning arbitrary "meaning" to the DAG
nodes and operations on them won't do the trick, sorry.
I'd like to reach some agreement on formal correctness of the RFC first,
and then discuss the meanings, the implementations, and other
consequences based on well-established formal base.
-- Sergey
