Re: rebase -i: quick/inline reword

Sergey Organov [off-list ref] writes:

quoted

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.

quoted

Nice.

Yeah, it is!

That part is still true ;-)