Bug UnityYAMLMerge: "File is not a valid text serialization YAML file"

Use Sourcetree with External merge tool UnityYAMLMerge (Unity 2019.4.11.f1)
Trying to rebase current branch (Inventory) to other branch (PlayerControl, it's the ancestor of current), which was before linked before.
I added to ancestor Add CM 2D vcam (2D vcam confiner and Tag Confiner) set vcam follow to Player Object.
And after that I Try rebase Inventory to updated PlayerControl.
In process of rebasing detected conflict merging of "TestScene.unity" file & I try by UnityYAMLMerge resolve it.

Receive error message "File is not a valid text serialization YAML file".
I checked Project setting on both branch - Asset serialization set direct to text.
I repeat twice and save temporary file which was created on process of merge (attempt1 & attemp2).
All times I receive error in "TestScene_BASE...TestScene.unity" file.
Also attached the "TestScene.unity" from Inventory/PlayerControl/ and "conflict merging"

 

I have never trusted YAML merge. Just a simple look at the structure of a YAML file to me says it probably does not have enough information to truly make a proper merge in all conditions.

An alternative approach is to rename one of the to-be-merged assets, commit it, do the merge and then bring them up side by side in the Unity Editor and go over them by hand.

This is an excellent reason why I like to slice my scenes up into lots of smaller additively-loaded scenes, such that the chances of a source control merge conflict is drastically reduced!

I also don't like rebase because it intentionally creates lies in the repository, states that never actually existed on anyones machine, making source control merge forensics essentially impossible.

 

Why do you think that?

IMHO the main problem of rebase (for Unity projects) - It's a merging scene files. If it did more logical and in more management style (don't merge the code lines in scene files, vs that - get from BASE & LOCAL GameObjects and merge on level completed GameObjects (replace/insert/del) or GameObject Components (also replace/insert/del) only.
Simple showing in Editor BASE and LOCAL variant in one time and give to developer to select (replace/insert/del) only or make the same automatically by premerge setting.

 

Because it creates lies in the git history! In the following image:



The two solid green dots never existed for testing. If you were investigating an issue, you would be surprised if something in the green was contravened by something in the center two yellow circles, because the person who did the work in green never saw the yellow dots. They were just "injected" at merge time without any testing.

 

After rebase branch, code have to go through full scope of test. In other cases you can receive some surprise.
But i think, in big projects (with many coders) it's a inevitably. How you will merge changes from other participants? In any case (by rebase or by install some patches) you will combine & merge code. You can select only level of automatization of this process. And all will finish by full testing or shift this procedure on the later time?
For free open project, where absent special team for integration changes,Is it exist other variants to combine work result from many people (vs use rebase "on git")?

 

After spending some time to understand result of work "git rebase" for Scene files in Unity. I decided, it's may be possible & interesting task - to write merger for "Scene files in Unity", but I have more interesting task now and going by your way:

1. In "New Base" branch make copy of Scene files ("OriginalScene") under different name - "SceneCopy".
2. In git made commit with this changes and after that make rebase of my other "Current Local" branch to this new commit.
3. In conflict merge selected - take the original Scene files from "Current Local" branch and "continue merge".
4. After that in Unity Editor copied changes objects from "SceneCopy".unity to original "OriginalScene".unity. Additionally, It's demanding to restore the link btw new copied GameObjects and "old" GameObjects existed in "OriginalScene").

P.S>
May be some automatic solution will work better in case of changes huge number objects, but in case changes of some number of objects this solution will be enough.
@Kurt-Dekker Thank you for idea
Sometimes a good way more good than the best way

 

Agreed. Same thing goes for automation. There is a practical upper limit to how much you can automate and engineer solutions.