… for the first time here https://musicbrainz.org/edit/68967621
but somehow it did it the opposite of what I expected. I thought it would merge remote to local, but it did the opposite. I don’t fully understand all effects, should this be cancelled and done again?
2 Likes
There’s an arrow that tells you which way the merge will happen (and you can click it to change that). Your impulse to merge into the more complete recording is the right one, but it shouldn’t make a huge difference.
It looks like you’ve got some votes already so you may as well leave it.
4 Likes
The mass merge script selects recordings with lowest row ID as target by default.
There are multiple reasons for that behavior:
- It’s assumed older entries have better data quality
- Some scripts depend on it and would need to manually refresh their database to detect changed MBIDs. (Most notably the collection highlighter)
Obviously the latter reason assumes that everyone who uses that script stores stuff with the oldest ID and merges of affected entities don’t go into the opposite direction…
I’m not happy with the practice of merging into older entries, especially if the newer one has better quality or proper name.
It has confused other editors often enough and those who are not auto-editors wouldn’t be able to quickly “fix” the name after merge.
4 Likes
Why would you have liked to merge pre-existing recordings into duplicates in this specific case?
Merging duplicates into pre-existing is a default because in most case it should be the thing to do.
Most recording name and comment edits are autoedits (add comment, case fix, apostrophe edit).
But it’s just a default, there are buttons to globally change all targets to local/remote and individual buttons fort reach recording merge.
For when there is any reason (recording name or comment) to merge into duplicates.
1 Like
The targets I had in mind had ISRC values, the others do not. I have read somewhere that this merge is destructive. Since I don’t know MusicBrainz that well yet I couldn’t foresee if any data gets lost.
1 Like
The irrevocable nature of merges
The destructive aspect of the merge, is its irrevocable nature.
We must be extremely careful because we cannot unmerge. Merge edits cannot be reverted.
Once a recording is merged, all its things from both recordings are now attached to merged recording and it becomes obscure from where this relationships, ISRC come from (if editor did not write edit note) or where this AcoustID comes from, etc.
Incorrect merges
If we spot an incorrect merge, the only thing we can do if quite a pity.
We have to recreate two recordings and attach only what’s verifiable, again, on each side.
Ideal merges
Here it’s really great, you really have used the script in its intended way, so don’t worry, merging tracks for two editions of the same album.
You just have to make sure, one of the editions is not a censored version (clean) of the other (explicit), an instrumental version, or even a mixed version where all tracks are cross faded, or all this kind of things.
The limited destructive aspect of (good) merges
Let’s say you merge a duplicate into a target.
The only things that are lost in merges are duplicate’s Name and Disambiguation comment.
- The Name can be found back in the closed Merge edit and on release tracklists, so it is not really lost.
- The disambiguation comment is, except for stand alone recordings, not visible in the merged recording edit history.
The names in particular can be easily batch set by editing a release with proper tracklist and checking the Copy all track titles to associated recordings checkbox of the Recordings tab.
So when we are about to lose a comment by a pending merge, it’s good to queue the comment on target recording, as a pending edit also (check _Make all edits votable), at the same time of the merge.
Sorry for this horribly complicated post. 
For everything except recording name and comment, the direction of the merge has no importance, the result is always the same: Everything if there, on the merged entity.
4 Likes
The post is certainly not complicated but a very informative summary, thanks!
2 Likes