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.
> > 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
> > 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,
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)?