Hi Sergey, 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. > > 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. > > 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...). 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)? Ciao, Johannes
