Are there any algorithms that can do or suggest merges without requiring the "base" file, the most recent common ancestor of the two file versions that we want to merge?

Is a manual merge between two files still considered a 'merge'.

2 Answers 2


Without a base file (a common ancestor of the files you want to merge) an automated algorithm can only tell that there is a difference between A and B, but it cannot tell if that is because A added some lines or B removed those lines.

When doing a fully manual merge, you can use knowledge that the computer doesn't have to tell how each difference must be resolved.

In short, a merge without a base file results in a merge conflict on every single difference between the files. That is not considered a useful merge by most people and thus most tools don't support it. What some tools do support is that you can copy changes from one file to the other in a two-file compare mode.

  • When you say "What some tools do support is that you can copy changes from one file to the other in a two-file compare mode." I believe that the tools let you select differences one by one and choose if you want that difference or not, correct? Otherwise it would be just be a file replacement if all the differences are copied.
    – yoyo_fun
    Commented Sep 24, 2023 at 12:25
  • 1
    @yoyo_fun, correct. You can select on the difference level (and sometimes on the line level) if it should be copied. Commented Sep 25, 2023 at 7:52

Except in special cases (for example you know that lines were only added - not deleted or changed) you need three versions of a file to do an automated merge. However it is not necessary for one of those three versions to be the "common ancestor".

Consider the case of a git cherry-pick when you choose a "commit'ish" to cherry-pick you are effectively selecting two versions - the commit and its immediate parent - you can also view this as a "patch" (list of lines added, changed and deleted).

You apply this patch to another arbitrary version (third version) as long as each change includes some context, so that the modified lines can be matched up correctly and there are no conflicts, the merge can be done cleanly.

I am not certain this is the exact logic that git cherry-pick uses - however the concept/algorithms is valid - see the Unix diff and patch commands.

In git, a merge can very loosely be defined as; any commit with more than one parent - in that depending upon your process it can be the case that a "merge" is an exact copy of one of it's parents - in this case the merge is only really tracking metadata for you - so that you know someone took a merge action.

Based on this definition: yes a manual merge is a merge - even if you simply chose one file (in it's entirety) and rolled with it.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.