Hi Sergey,
On Tue, 27 Mar 2018, Sergey Organov wrote:
> Johannes Schindelin <Johannes.Schindelin@xxxxxx> writes:
> >
> > On Tue, 13 Mar 2018, Igor Djordjevic wrote:
> >
> >> On 12/03/2018 13:56, Sergey Organov wrote:
> >> >
> >> > > > I agree with both of you that `pick <merge-commit>` is inflexible
> >> > > > (not to say just plain wrong), but I never thought about it like
> >> > > > that.
> >> > > >
> >> > > > If we are to extract further mentioned explicit old:new merge
> >> > > > parameter mapping to a separate discussion point, what we`re
> >> > > > eventually left with is just replacing this:
> >> > > >
> >> > > > merge -R -C <original--merge-commit> <merge-head>
> >> > > >
> >> > > > ... with this:
> >> > > >
> >> > > > pick <original--merge-commit> <merge-head>
> >> > >
> >> > > I see where you are coming from.
> >> > >
> >> > > I also see where users will be coming from. Reading a todo list in
> >> > > the editor is as much documentation as it is a "program to execute".
> >> > > And I am afraid that reading a command without even mentioning the
> >> > > term "merge" once is pretty misleading in this setting.
> >> > >
> >> > > And even from the theoretical point of view: cherry-picking
> >> > > non-merge commits is *so much different* from "rebasing merge
> >> > > commits" as discussed here, so much so that using the same command
> >> > > would be even more misleading.
> >> >
> >> > This last statement is plain wrong when applied to the method in the
> >> > [RFC] you are replying to.
> >
> > That is only because the RFC seems to go out of its way to break down a
> > single merge commit into as many commits as there are merge commit
> > parents.
>
> Complex entity is being split for ease of reasoning. People tend to use
> this often.
Sure. Divide and conquer. Not duplicate and complicate, though.
> > This is a pretty convoluted way to think about it: if you have three
> > parent commits, for example, that way of thinking would introduce three
> > intermediate commits, one with the changes of parent 2 & 3 combined, one
> > with the changes of parent 1 & 3 combined, and one with the changes of
> > parent 1 & 2 combined.
>
> No.
Sorry. This is unacceptable. If you disagree, sure, you are free to do
that. If you want to contribute to a fruitful discussion, just saying "No"
without explaining why you *think* that my statement is wrong is just...
unconstructive.
> > To rebase those commits, you essentially have to rebase *every
> > parent's changes twice*.
>
> No.
Same here.
> > It gets worse with merge commits that have 4 parents. In that case, you
> > have to rebase every parent's changes *three times*.
>
> Sorry, the [RFC] has nothing of the above. Once again, it's still just
> as simple is: rebase every side of the merge then merge the results
> using the original merge commit as a merge base.
>
> And if you can't or don't want to grok the explanation in the RFC, just
> forget the explanation, no problem.
Your RFC talks about U1 and U2, for the two merge parents.
Obviously this strategy can be generalized to n parents. I thought you had
thought of that and simply did not bother to talk about it.
Sorry, my mistake. I should not assume so much.
> > And so on.
> >
> >> > Using the method in [RFC], "cherry-pick non-merge" is nothing more or
> >> > less than reduced version of generic "cherry-pick merge", exactly as
> >> > it should be.
> >
> > I really get the impression that you reject Phillip's proposal on the
> > ground of not being yours. In other words, the purpose of this here
> > argument is to praise one proposal because of its heritage, rather than
> > trying to come up with the best solution.
>
> No. As the discussion evolved, I inclined to conclusion that modified
> Phillip's algorithm is actually better suited for the implementation
> [1].
Again a link.
If that's what you are looking for, I will throw a hundred links your way
and see how constructive a discussion you find that.
> > On that basis, I will go with the proposal that is clearly the simplest
> > and does the job and gets away with avoiding unnecessary work.
>
> These algorithms are actually the same one, as has already been shown
> elsewhere in the discussion.
I disproved that already. My example showed that instead of reconciling
the diverging changes starting from the original merge parents, RFC v2
tries to rebase those parents first, and then use the original merge
commit as base of "diverging changes" that never started from that
original merge commit.
Essentially, where Phillip's strategy imitates a cherry-pick's 3-way
merge, your strategy tries to rebase the merge tips independently from the
user (who already rebased them, thank you very much), and then runs a
*revert*: while a cherry-pick uses the picked commit's parent as merge
base, a revert uses the to-be-reverted commit itself as merge base.
In short: Phillip's strategy is only equivalent to yours if you ignore the
fact that you perform unnecessary work only to undo it in the end.
> Asymmetric incremental nature of the Phillip's one is apparently better
> suited for naturally asymmetrical way Git already handles merging. FYI,
> here is the latest proposal that came out of discussion [1]:
And another link.
> git-rebase-first-parent --onto A' M
> tree_U1'=$(git write-tree)
> git merge-recursive B -- $tree_U1' B'
> tree=$(git write-tree)
> M'=$(git log --pretty=%B -1 M | git commit-tree -pA' -pB')
> [ $conflicted_last_merge = "yes" ] ||
> trees-match $tree_U1' $tree ||
> stop-for-user-amendment
And a bunch of commands from which the reader is expected to deduce the
idea.
> >> > Or, in other words, "cherry-pick merge" is generalization of
> >> > "cherry-pick non-merge" to multiple parents.
> >>
> >> I think Sergey does have a point here, his approach showing it.
> >
> > His approach is showing that he wants to shoehorn the "rebase a merge
> > commit" idea into a form where you can cherry-pick *something*.
> >
> > It does not have to make sense. And to me, it really does not.
>
> Except that Phillip's one does exactly this as well, only in incremental
> manner, as shown in [1].
And yet another link.
> >> Phillip`s simplification might be further from it, though, but we`re
> >> talking implementation again - important mental model should just be
> >> "rebasing a commit" (merge or non-merge), how we`re doing it is
> >> irrelevant for the user, the point (goal) is the same.
> >
> > Except that Phillip's simplification is not a simplification. It comes
> > from a different point of view: trying to reconcile the diverging
> > changes.
>
> They are essentially the same as one easily converts to another and back
> [1].
Repeating this does not make it more true.
With your method, this branch structure:
- A - B
\ \
C - D
would be rebased by first cherry-picking B, then C, then doing it *again*
because you need to construct U1 (which is kind of C) and U2 (which is
kind of B) and rebase those, and if the user resolved merge conflicts
while rebasing B, those merge conflicts will have to be resolved *again*
when rebasing U2, and if the user dropped part of B, U2 will still have to
rebase them, and the final merge with the original D as merge base will
have to undo those changes.
Your strategy involves *a lot* more work, and *a lot* more opportunities
for merge conflicts, and it also allows for giving incongruent answers
to the question "what should the tree of the rebased merge commit look
like?".
> They will only bring different user experience in case of conflicts.
Oh yes, they do. The amount, to begin with.
> > Phillip's is a true generalization of the "rebase vs merge" story: it is
> > no longer about merging, or about rebasing, but about reconciling
> > divergent commit histories, with whatever tool is appropriate.
>
> Whatever. They are essentially the same thing. The only difference is
> incremental vs parallel [1].
You know, if you promise to answer whatever questions I have, just simply
stop throwing around links. Answer my questions. To the point. Not
deflecting. This is getting ridiculous.
> [1] https://public-inbox.org/git/87efkn6s1h.fsf@xxxxxxxxx/
I will allow myself the joke and answer the concerns you had in this mail
thusly:
https://public-inbox.org/git/nycvar.QRO.7.76.6.1803261405170.77@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx/
So that you cannot miss it: there is a really good, real-world example
showing why Phillip's strategy is so much more practical than yours,
proving that they are not equivalent (except in a very narrow, purely
theoretical sense that ignores the possibility of merge conflicts). Look
for "concrete example" in that mail.
Another most important thing from that mail is really, really important.
So I will stress it instead of expecting you to pick up on it, by
repeating it here:
BTW this is the level of detail I would have wished your answers
to my repeated questions for clarification of your RFC v2 to be.
And that is what I expect in response to my valid questions in the
future.
Instead, you chose to fling a link in my direction again.
And yes, I read your mail, and no, it does not clarify anything, or even
addresses my objections.
If you contest my understanding of your strategy (where I say that U1 is
essentially the changes of the *other* merged branch), you will have to do
a much better job at explaining yourself. "No" is definitely not adequate.
And don't promise to answer my questions if you plan only on throwing a
link at me. That is no good.
So to repeat my point (that you contested without any argument, by a rude
and totally unmeritedly terse "No"):
> > To rebase those commits, you essentially have to rebase *every
> > parent's changes twice*.
>
> No.
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
You now insert U1 and U2 with trees identical to M:
- B1 - U1
\
- B2 - U2 - M
So U1 is essentially B2 cherry-picked on top of B1, and U2 is essentially
B1 cherry-picked on top of B2.
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.
Now, the changes in U1/U2 *are* the changes of the merge parents, that's
how they were constructed.
Since they repeat what B1 and B2 are about, 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*.
The answer "No" to this is... astonishing.
Ciao,
Johannes
