Sergey Organov <sorganov@xxxxxxxxx> writes: >> 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 ;-)
