GedMend › Guides

How to check a merge did not lose anything

You have a merged file. Before it becomes the tree you work in, three checks will tell you whether it did what you asked — and none of them requires trusting the tool that made it.

Last updated 26 August 2026

Check 1 — the arithmetic

There is one equation, and it catches an entire category of failure:

people in file A + people in file B − pairs you confirmed as the same
    = people in the merged file

Every pair you confirm removes exactly one duplicate, so the total must come out exactly. Not approximately — exactly. Run the same check separately for families, where the same logic applies.

If the numbers agree, nothing was invented and nothing was dropped. If they do not, the merge has done something you did not ask for, and it is worth knowing that before the file becomes your working tree rather than after.

You can run this by hand if you need to: most genealogy programs will tell you how many individuals a file contains, and the count of pairs you confirmed is something a merge report should state directly.

Check 2 — read the surviving-duplicates list

A good tool will tell you which pairs scored highly and were not confirmed as the same person. Both records will be in the merged file. This is not an error, and it is frequently the correct outcome.

It happens in two quite different ways, and no tool can tell them apart:

• You looked at the pair and deliberately answered not the same, and both records staying is exactly what you asked for.
• You never reached the pair at all, because it sat below the threshold you were working at.

Which is why the list exists: the tool names the pairs and leaves the judgement to you. Read it. If every pair on it is one you consciously separated, you are finished. If a name makes you pause, go back to the matching step, find that pair, and look again.

Check 3 — the citations on your best-sourced people

Citations are the most commonly lost thing in a merge and the least commonly checked. The efficient test is not a random sample; it is a targeted one.

Before merging, pick two or three people you have sourced most heavily — the ones where you know there are four or five citations — and note the numbers. Afterwards, look at those same people. If a merge report gives per-person counts in the form A=2 B=3 merged=4, the arithmetic is direct: two plus three, minus the one that appeared identically in both, is four.

The rule that catches real problems: a merged count should never be lower than the larger of the two inputs. If it is, evidence has been discarded.

The citations guide covers what should and should not be collapsed — in particular why two references to the same register at different folios are not duplicates and should both survive.

Two more things worth ten minutes

Look at the accented names

Find three or four people whose names carry accents and check they read correctly. Encoding damage shows up in the display of text and nowhere else — it will not affect a count, so check 1 cannot catch it. See the accented names guide.

Open fifteen of the people you merged

Import the result as a new tree rather than over your master, and then look at fifteen or twenty merged individuals: their dates, their parents and children, their sources. This is the check that finds problems arithmetic cannot — a right count with wrong contents. If those fifteen are right, the rest almost certainly is, and only then should the merged tree become the one you work in.

Keep the report

Whatever tool you used should have written a record of every match confirmed, every field decision, and whether each was your choice or a default. Keep it beside the merged file.

The reason is not the merge; it is next year. When you wonder why a birth year reads 1834 and not 1836, that report is the only thing that can answer it — and the distinction between "you decided this" and "this was the default" is exactly the one you will want.