Unmerge vs Restore

LegacyUser

bgdudley said: Unmerge vs Restore
The article "How do I undo a merge in Family Tree?" (72004) includes the statement in point 6 states "If this merge cannot be undone automatically, the Restore option is not available. The merge must be undone manually."

There are no steps to show how the merge is to be undone manually. This is such a confusing statement, especially for those new to using FamilySearch.org but even long time users are confused. It is not intuitive to click on the deleted person and delve deeper into the deleted person's record to find the Restore button.

There is an article " How do I restore a deleted record for a person in Family Tree?" (57078) that explains what to do to restore a incorrectly merged record.

Can this article be noted with step 6 or at least added into Related Articles.

LegacyUser

gasmodels said: Agree the first article is a huge mistake and will only lead to duplicates if followed. In fact the statement after your quote about manual undone is this statement. '' To do this, you create a new record for the deleted person and make sure that each person contains the correct information." I do not know who wrote this but in my opinion this is a major mistake. One of the original purposes of Family Tree was to eliminate duplicate records. Suggesting we create new records seems counter to that purpose.

LegacyUser

Tom Huber said: There are instances where the instructions to create a new profile must be followed, but for most of us without Church ancestry, that will be very rare and usually associated with end-of-line ancestors (where nothing is known of the parents).

The UnMerge ability is limited only to those profiles where a merge took place and no other changes (of any kind) were applied to the surviving record. That unmerge takes place as a "restore" (a bad term in this instance, but means both records are restored to their individual states before the merge took place). Once a change takes place to the surviving record, that particular "restore" goes away.

At that point, the record deleted by the merge must be opened and restored from the remnants of the deleted record. The state of the restored deleted record is what it was at the time of the merge.

The so-called manual restore that involves creating a new record should not be done unless the deleted record has no option to restore it. The combined record was likely created when the nFS (new Family Search) tree was still connected to the FamilySearch tree or, "Joined at the hip" and there is insufficient remains of the merge in the change log, if any remnant of the merge is actually included.

At that point, the only option is to create a new version of the profile, complete with sources and connections to the family. If a duplicate profile already exists, then use that duplicate record to rebuild the full record of the deleted profile.

Do not created a new profile, since the basis for one already exists. Instead take the duplicate profile and process all applicable hints and possible merges and then look for other possible merges based upon dates, places, and connected family. Use the same care to make sure that you are not merging two children with the same name, one of which died before the other was born.

LegacyUser

Adrian Bruce said: Yes I was going to add that there are circumstances where ''create a new record for the deleted person and make sure that each person contains the correct information" makes sense - but as far as I know, in theory that's confined to cases where the "merge" took place in nFS (as Tom suggests) so you can't actually see a merge in FSFT, nor is there a deleted person in FSFT. (Yes, the term "merge" isn't quite appropriate for nFS I believe)

I emphasise "in theory" because sometimes it just isn't possible to find that deleted person within the time limits we all have to live with. I know that a few months ago, I was disentangling a pair of ancestors who'd been merged with 4 pairs of ancestors of the same name from across England. Apparently someone had thought that people in 1700s England were well equipped with fast horses to move back and forth between Cheshire, Devon and Kent having children in each county in turn. (Not to mention a TARDIS to get to Lincolnshire after their deaths in Cheshire...)

Well, I managed to restore all the merge-deleted mothers and then I went on to the merge-deleted fathers. One I just could not find in a sensible timescale - maybe he'd been merged into a merge that was itself merged into another merge...? Leaving the two merged together was a hostage to fortune because that was still prompting the system that a guy from Cheshire was also having children in Devon, so I had to create a new, clean record for the guy that I couldn't find and transfer the relevant data to him. There was no other viable way forward. None of that is easy to explain - and maybe not safe to explain to newbies!

LegacyUser

gasmodels said: Exactly the situation where a new record is required. In the majority of situation it can be extracted from the original by careful analysis.

LegacyUser

Jeff Wiseman said: When you create a new record to replace a PID that was "archived" (i.e., deleted) via a merge, it is basically just creating another duplicate that DOESN'T have the change history, temple ordinance work, and origin information of the original. By creating a new record instead of restoring the original, you pretty well lose all of the original information since there will no longer be any obvious need to restore the old record.

Whenever possible, it should always be restored from the archive and the scrambled surviving PIDs of previous merges cleaned up. People think that when it gets "too complicated" to restore a PID, then starting all over again by creating a brand new PID is acceptable. Unfortunately, all this is really doing is obfuscating the original record with all of the pertinent histories.

That being said, some people can really scramble PIDs through bad merges and "tweaking" to the point that it's pretty hard to do anything logical in the lines of fixing things...

LegacyUser

Adrian Bruce said: Is it currently possible to come up with some sort of query that would list all the PIDs that contribute to an existing profile? I don't know of one but that would be far more useful than trying to delve through merges into merges into merges. Maybe that way I would have found the missing PID that I couldn't find just by looking through Change Histories.

Remember, Jeff, I can see none of the stuff that is, quite correctly, important to the Church, and from where I'm sitting, a new PID with none of the pre-existing garbage makes sense. So if the Church is really serious about unravelling merges into merges into merges into merges..... in a fashion useful to the Church - it would help to give us all the tools.

LegacyUser

Tom Huber said: Hi Adrian. That is an excellent idea. Why don't you start a new discussion thread requesting a list of all PIDs that have been merged into a profile. For some, the list will be extensive and for others, not so much.

I believe this has been requested in the past (more than a year or three ago), but rather than chase down the original request, start a new one.

LegacyUser

Jeff Wiseman said: Yea, the search would just recursively walk down the change history entering each merge that ever existed on ANY of the PIDs that were deleted and collecting the PIDs.

LegacyUser

Tom Huber said: These should already be tracked in order to get the earliest vicarious temple (Church) ordinances associated with a profile. Hopefully, that could be used for this purpose.

LegacyUser

Adrian Bruce said: Done as suggested - see https://getsatisfaction.com/familysea...