Hi Johannes, Johannes Schindelin <Johannes.Schindelin@xxxxxx> writes: > Hi Sergey, > > On Tue, 27 Mar 2018, Sergey Organov wrote: > >> Johannes Schindelin <Johannes.Schindelin@xxxxxx> writes: >> >> > On Mon, 12 Mar 2018, Sergey Organov wrote: >> > >> >> Johannes Schindelin <Johannes.Schindelin@xxxxxx> writes: >> >> > >> >> > On Wed, 7 Mar 2018, Sergey Organov wrote: >> >> > >> >> >> Johannes Schindelin <Johannes.Schindelin@xxxxxx> writes: >> >> >> >> >> >> > How can your approach -- which relies *very much* on having the >> >> >> > original parent commits -- not *require* that consistency check? >> >> >> >> >> >> I don't understand what you mean, sorry. Could you please point me >> >> >> to the *require* you talk about in the original proposal? >> >> > >> >> > Imagine a todo list that contains this line >> >> > >> >> > merge -C abcdef 123456 >> >> > >> >> > and now the user edits it (this is an interactive rebase, after >> >> > all), adding another merge head: >> >> > >> >> > merge -C abcdef 987654 123456 >> >> > >> >> > Now your strategy would have a serious problem: to find the >> >> > original version of 987654. If there was one. >> >> >> >> We are talking about different checks then. My method has a built-in >> >> check that Pillip's one doesn't. >> > >> > Since you did not bother to elaborate, I have to assume that your >> > "built-in check" is that thing where intermediate merges can give you >> > conflicts? >> > >> > If so, there is a possibility in Phillip's method for such conflicts, >> > too: we have to perform as many 3-way merges as there are parent >> > commits. >> > >> > It does make me uncomfortable to have to speculate what you meant, >> > though. >> >> It doesn't matter anymore as this check could easily be added to >> Phillip's algorithm as well, see [1]. >> >> [1] https://public-inbox.org/git/87efkn6s1h.fsf@xxxxxxxxx > > Ah, and there I was, thinking that finally you would answer my questions > directly, instead you keep directing me elsewhere ("read that! Somewhere > in there you will find the answer you are looking for"). Except I've copy-pasted it for /you/ from that reference in another answer to /you/, and /you/ denied it there as being unexplained. As it actually happens to be discussed and explained in the referenced material, should I rather copy-paste the entire reference to fulfill your requirements? Here I repeat, directly again, that essential quote from that reference, in case you forgot it: <QUOTE> 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 where 'git-rebase-first-parent' denotes whatever machinery is currently being used to rebase simple non-merge commit. </QUOTE> > My time is a bit too valuable, and I will not continue a discussion where > my questions are constantly deflected that way. No deflection on my side was ever intended. The referenced discussion actually has explanations. Maybe one whole page of reading, and it is to be read in context, and then a few follow-ups in that discussion could also be of interest, provided you are interested. I'm sorry should you have no time for that. -- Sergey
