If you merge entity A with entity B, and B is being merged with entity C, but B -> C happens first, then A -> B fails. If the outcome of merging is that the merge target takes on the identity and relationships of the merge subject, I don’t understand why the system can’t handle this. It seems like simple logic, A=B and B=C therefore A=C.
Is there a ticket for this by any chance? It’s quite a nuisance trying to keep track of C so I make sure that A and D and E all get merged with it instead of B.
if i understand you right. IMHO you should have a -> b happen first then b -> c . you can not merge with b after it is merged with c as it is no longer b. and y dont you just merge both with c. so a -> c and b -> c seeing as tho that from the sounds of it is what you are trying to make happen?
My point is that the effect of a merge is that B and C are now the same, so a merge with B should automatically become a merge with C. B is not gone, because a merge makes the MBID of B point to C.
Sometimes it is easier to work with the quirks of the system. When merging lots of loose tracks like that I’ll try and focus on making one recording or one release the target for everything. Waterfall merges are prone to fail, and could be argued are against guidelines. The guideline is to merge towards the item with the most details.
Though my tendency is to do this from the other side. Merging stuff that has already merged due to other merges I have queued up. I can end up with a little collection of messages from modbot after a big merge session.
I also have bookmarked a few searches that let me return a week later and have a check of all the merges I have performed that week. Not just to check if the merge went in the right direction, but to make sure the correct info went with it. Clean up any duplicated data.
I always try to target the most detailed/earlier release. Sometimes I misjudge, if there’s not a clear way to distinguish them on the merge screen. And sometimes I start a few merges based on that principle, and then find out further down the road that there’s another merge that needs to happen that really should be the overall target. Depending on the amount of work involved in doing the research and providing justification on the earlier merges, changing them to the new target seems like a waste of time and energy, and just adds confusion to the mix. The most efficient thing would be to cancel the lot and do a many-to-one merge, but then it’s harder to provide evidence relevant to specific recordings.
Yeah, I know the kind of “down the rabbit hole” merge journeys you are talking of. If I see something like that after having setup loads of merges, I put it in my diary for returning to in seven days time.
That’s why that bookmark link I added above is so handy to me. Acts as a good memory jog as to where I had got to in a mass merge clear-ups.
If I see something like that after having setup loads of merges, I put it in my diary for returning to in seven days time.