Johannes Schindelin <Johannes.Schindelin@xxxxxx> writes: > Hi Sergey, > > 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
