GedMendby CaliberUtilities
← Back to GedMend

GedMendGuides

What happens to your source citations when you merge two trees

The evidence behind a fact is not the fact. Here is what a merge should do with your citations, what it should never do, and how to check which one happened.

Last updated 1 September 2026

The short answer. It depends entirely on the tool, and the difference is not cosmetic. When two records for one person are combined, the merged record should carry the citations from both — and choosing one file's birth year should not discard the other file's evidence for its birth year. The value is a decision. The citations are kept regardless.

An unsourced tree is a rumour. A merge that keeps facts and drops the evidence behind them has converted research into hearsay, silently.

The three places a citation can live

Genealogy programs differ in where they attach evidence, and a merge has to respect all three or it quietly degrades your file:

The behaviour to insist on is that each one stays where it was. A citation attached to a birth should arrive still attached to that birth, not loosened into a general note about the person. A tool that flattens event-level citations up onto the individual has not lost any data in a way you can count — and has still destroyed most of their value, because a citation that floats free of the event it supports no longer proves anything in particular.

The case that surprises everyone

Suppose File A cites Parish Register, folio 3 and File B cites Parish Register, folio 4. Should the merged record keep one or both?

Both. They are not a duplicate. They are two different pages of the same book, and each supports something. Only citations identical in every part — the page, the date, the note attached — should be folded into one. Anything less than identical is separate evidence.

This is why a merged file can look as though it has "the same source twice". Read the detail before tidying it away; you will usually find it does not.

Choosing a value is not choosing a source

Your file says the birth was 1834, citing folio 3 of the parish register. The incoming file says 1836, citing folio 9 of the same register. You keep 1834. What becomes of folio 9?

It should survive, and it should stay on the birth. Three other things could happen to it, and all three are worse. It could be discarded along with the year it supported — evidence lost, silently, and not visible in any count. It could be loosened up onto the person, where it still counts but no longer says what it is evidence for. Or it could be rewritten to look like support for the year you kept, which is the worst of the three: dropping a citation loses information, and that one invents it.

GedMend does the first. One birth, reading 1834, carrying folio 3 and folio 9 both — nothing dropped, nothing loosened onto the person, and no citation altered to claim a value it never supported. The limit is the format's: GEDCOM attaches a source to an event, not to a date inside one, so folio 9 stays on a birth whose date now reads 1834, and the file itself no longer records that folio 9 was the reason anyone wrote 1836. The change report does — it lists the value you chose for every conflict.

If you need that distinction kept in the file rather than in the report, choose keep both. GEDCOM permits two birth structures on one person, and that is what GedMend then writes: 1834 with folio 3, 1836 with folio 9, each year carrying its own evidence on its own event. It is the honest shape for a disagreement you have not settled, and the only one that says which source supports which year.

The two mistakes are not equal, and that asymmetry should drive the design. Keeping a citation you did not need costs you one tidy-up, at leisure, with everything in front of you. Discarding one because it looked similar to another loses evidence you may not be able to find again — and you would never know it had happened. A merge tool should err in the direction you can recover from.

Why your source list may look longer afterwards

Most files keep a list of the sources themselves — the registers, censuses and certificates — with citations pointing into it. When two files are merged, both lists arrive, along with any repository details: which archive holds the original, and its call number or shelf mark.

So if both of your files independently describe the same parish register, you will see it twice in the merged source list. That is expected, and collapsing the two would be the wrong move: no tool can safely tell that two descriptions of a register are the same physical thing, and quietly merging them repoints every citation that relied on them. Merging duplicate sources is a tidying job your main genealogy program is better placed to do, once you can see them side by side and judge for yourself.

It is worth separating the two ideas, because they are easily confused. Duplicate people are what a reconciliation tool exists to find. Duplicate source records are a different job, done later, in a different program.

How to check it actually happened

You do not have to take any of this on trust, and you should not. A merge report should give you the numbers for every person merged, in a form like this:

Citations: A=2 B=3 merged=4

Two from File A, three from File B, four in the result — meaning one citation was present in both files identically and folded into a single entry. Add the two inputs, subtract the number that folded, and you have the total that should be there.

The rule of thumb that catches real bugs: a merged count should never be lower than the larger of the two inputs. If a person had three citations in File B and the merged record has two, something has been discarded. That is worth reporting to whoever wrote the tool.

Before you merge: two minutes well spent

  1. Pick two or three people you have sourced most heavily — the ones where you know there are four or five citations, and roughly what they are.
  2. Write the numbers down before the merge.
  3. Check those same people afterwards. If the heavily-sourced people came through intact, the lightly-sourced ones almost certainly did too.

This is a better test than checking a random sample, because the failure mode you are looking for concentrates where there is most to lose.

The tool this came from

GedMend is a Windows program that reconciles two GEDCOM files before either one is modified. It proposes which records are the same person and shows the reasoning behind each proposal, puts every disagreement in front of you to decide, preserves every source citation, warns when the two files use different encodings, and writes a brand-new merged file. Your original files will not be changed.

See how GedMend works

Everything is free — load, review, resolve, see the report; export is a one-time purchase. Nothing expires. Windows 10 (1809) or later, 64-bit.