Hi Johannes, Johannes Schindelin <johannes.schinde...@gmx.de> writes: > Hi Sergey, > > On Wed, 7 Mar 2018, Sergey Organov wrote: > >> Johannes Schindelin <johannes.schinde...@gmx.de> 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. All the external checks, if any, will have to be the same. > >> > What would your approach (that still has no satisfyingly trivial >> > explanation, in my mind) >> >> Here is one-liner: rebase sides of the merge commit and then 3-way >> merge them, using original merge commit as merge base. > > But I already pointed out how that would undo a commit having been > dropped. No. Not for this version. You did it for originally flawed version of the method, that has been already fixed by addition of "using original merge commit as merge base" in the above sentence, and that was the exact reason for [RFC v2], that in turn is explicitly stated at the beginning of [RFC v2]. > >> > do if somebody edited a `merge` command and let it merge a completely >> > unrelated commit? >> >> Don't see a problem, sorry. The method should still work, provided you have >> original merge commit and two new parents for the new merge. > > That is assuming a lot. That is exactly what this consistency check is > for, that I mentioned earlier, and which you listed as a downside of > Phillip's strategy (forgetting that your strategy has the same downside, > so...). Again, we are talking about different checks. My method has a built-in check that Pillip's doesn't. All the external checks, if any, will have to be the same. > But I guess that you are still talking about the non-interactive version > of the rebase, and missed that our conversation proceeded to the point > where we want that same strategy to work *also* in the interactive version > (and not have a completely different functionality depending whether you > use --interactive or not)? For me, non-interactive is an interactive one with unmodified todo list. -- Sergey
