Re: rebase -i: quick/inline reword

From: Junio C Hamano <gitster@pobox.com>
Date: Aug 16, 2020, 16:55 UTC
Message-ID: <xmqqy2me4jj6.fsf@gitster.c.googlers.com>
In-Reply-To: <87imdipymt.fsf@osv.gnss.ru>

Sergey Organov <sorganov@gmail.com> writes:

Show 9 quoted lines

>> I only looked at its description but the UI the tool does it with
>> looks quite obvious and intuitive.  From its source, the "merge"
>> operation does not seem to handle merging a side branch that renamed
>> files, but that should be OK most of the time, I presume.
>
> From the docs:
>
> No merge commits may occur between the target commit and HEAD, as
> rewriting them is not supported.

I didn't read the documentation that deeply, but it's irrelevant that the tool can handle only a single strand of pearls.

You need a merge machinery to implement even a cherry-pick of a single parent commit; an obvious way to implement cherry-pick of commit C on HEAD is to perform three-way merges between C and HEAD, pretending as if C^1 is their sole common ancestor.

Our cherry-pick uses the merge-recursive machinery to do so, and because the sequencer inherited the idea and implementation, "git rebase -i" does the same. They instead use their own written in Python to merge at the tree-level and farms the content-level merge out to "git merge-file".

The "recursive" part of the "merge-recursive" machinery we use does not help cherry-pick at all (as we use only one "common"), but it handles renames. They can do the same in their merge_trees(), but they currently don't.

But as I said, that should be OK most of the time, I would think.

>> Nice.
>
> Yeah, it is!

That part is still true ;-)