# Need help with a strange merge
**URL:** https://community.metabrainz.org/t/need-help-with-a-strange-merge/815711
**Category:** MusicBrainz
**Tags:** merge, musicbrainz
**Created:** [September 28, 2026, 4:32pm UTC](https://community.metabrainz.org/t/need-help-with-a-strange-merge/815711 "2026-09-28T16:32:50Z")
**Posts on this page:** 4
**Page:** 1
### Author:  [@karpuzikov](https://community.metabrainz.org/u/karpuzikov)
#### Post date: [September 28, 2026, 4:32pm UTC](https://community.metabrainz.org/t/need-help-with-a-strange-merge/815711/1 "2026-09-28T16:32:50Z")
So I’m checking out if linked recordings are correct, in [this release](https://musicbrainz.org/release/cb87dcb4-6100-4ef0-8b09-197d138f15df) and for some reason there is 5 random tracks in the middle of the tracklist linked to one recording.
In the history I found [my edit which was releases merge](https://musicbrainz.org/edit/147769155) and what is baffling for me is that in this edit with the merge of releases, 5 random tracks were merged into one as well.
How that could happend?
---
### Author:  [@IvanDobsky](https://community.metabrainz.org/u/IvanDobsky)
#### Post date: [September 28, 2026, 5:08pm UTC](https://community.metabrainz.org/t/need-help-with-a-strange-merge/815711/2 "2026-09-28T17:08:13Z")
> [@karpuzikov](#):
>
> How that could happend?
Computers are really efficient at making a mess… 😂
The important thing is the human has spotted it.
Without reading 16 pages of edits it is hard to work out what actually happened. Maybe someone did a merge on AcoustIDs. Or just a plain slip of the mouse. Trouble is with smaller artists there are not many eyes on the edits to catch a mistake like that.
---
### Author:  [@VBZPPlNQyJ](https://community.metabrainz.org/u/VBZPPlNQyJ)
#### Post date: [September 28, 2026, 6:16pm UTC](https://community.metabrainz.org/t/need-help-with-a-strange-merge/815711/3 "2026-09-28T18:16:26Z")
> [@IvanDobsky](#):
>
> Trouble is with smaller artists there are not many eyes on the edits to catch a mistake like that.
And for the biggest artists, there are too many edits to keep track of
---
### Author:  [@chaban](https://community.metabrainz.org/u/chaban)
#### Post date: [September 28, 2026, 7:45pm UTC](https://community.metabrainz.org/t/need-help-with-a-strange-merge/815711/4 "2026-09-28T19:45:26Z")
I couldn’t be arsed to look at all those edits myself either, so I let an AI tool do the work.
> ****
>
> The unexpected merge in [Edit #147769155](https://musicbrainz.org/edit/147769155) happened due to a combination of an **off-by-one tracklist mismatch between the two releases** , a **prior recording merge** , and the **transitive merge-target resolution logic in MusicBrainz Server**.
>
> * * *
>
> ### 1. The Tracklist Offset (Off-by-One Mismatch)
>
> When merging the two 39-track releases:
>
> - **Destination release** (`4556252`, added in [Edit #115717678](https://musicbrainz.org/edit/115717678)):
> - Had _“Laissez‐moi tranquille”_ at track 8.
> - Omitted the track _“Tu ne le vois pas”_ entirely.
>
> - **Source release** (`5629823`, added in [Edit #143113063](https://musicbrainz.org/edit/143113063)):
> - Omitted _“Laissez‐moi tranquille”_ (track 8 was _“Mi Gna”_).
> - Included _“Tu ne le vois pas”_ at track 11.
>
> Because both releases had exactly 39 tracks, tracks 8 to 11 were shifted by 1 position:
>
> | Pos | Destination Release (`4556252`) Track & Rec ID | Source Release (`5629823`) Track & Rec ID |
> | --- | --- | --- |
> | **8** | _Laissez‐moi tranquille_ (`22422261`) | _Mi Gna_ (`22275655`) |
> | **9** | _Mi Gna (remix)_ (`22275655`) | _Tu reviendras_ (`22422262`) |
> | **10** | _Tu reviendras_ (`22422262`) | _Nos valeurs_ (`22422263`) |
> | **11** | _Nos valeurs_ (`22422263`) | _Tu ne le vois pas_ (originally `22422264`, see below) |
> | **12** | _Merci maman_ (`38590238`) | _Merci maman_ (`38590238`) |
> | **13** | _T’es partie_ (`22422266`) | _T’es partie_ (`22422266`) |
>
> * * *
>
> ### 2. The Prior Merge That Closed the Chain
>
> In [Edit #143113178](https://musicbrainz.org/edit/143113178), editor `maggielou` merged recording `22422264` into `38590238` (_“Merci maman”_).
>
> When that edit applied, all tracks pointing to `22422264` were redirected to `38590238`. As a result:
>
> - Track 11 on the source release became `38590238`.
> - Track 12 on **both** releases was now `38590238`.
> - Because `newr.id == oldr.id` at track 12 (`38590238 == 38590238`), track 12 was excluded from the merge candidates (`WHERE newr.id != oldr.id`), and track 13 onward were already identical.
>
> * * *
>
> ### 3. The Server Merge Algorithm (MBS-8614 Transitive Collapse)
>
> When selecting the strategy **“Merge mediums and recordings”** (`merge_strategy = "2"`), MusicBrainz runs `determine_recording_merges` in [`MusicBrainz::Server::Data::Release`](https://github.com/metabrainz/musicbrainz-server/blob/master/lib/MusicBrainz/Server/Data/Release.pm#L1139):
>
> 1. **Candidate query:** It matches tracks sharing the same position where `newr.id != oldr.id`:
>
> 2. **Chaining logic (MBS-8614):**
> To prevent intermediate recordings from being merged into deleted sources (e.g. `1 -> 2` and `3 -> 1`), MusicBrainz traces `target`:
>
> ### Summary
>
> Because each track in positions 8–11 on the destination release had the same recording as the _preceding_ track on the source release, the transitive merge resolution chained them all together. Rather than creating 4 separate positional merges (or failing), the algorithm collapsed the entire 4-track domino sequence into the root target at track 8: **“Laissez-moi tranquille”**.