Hey there! Thanks for the constructive feedback. In the interest of full disclosure, while I still use UniMerge in my own workflow, and I want to provide timely support, maintaining UniMerge isn't my day job, and thus I can only spend some of my spare time working on maintenance and improvements. With that said, I have some good news! I just finished publishing version 1.14, which brings a much-needed overhaul to the comparison filters, and I have some more downtime over the holidays to take a fresh look at git integration. With that said, let me respond individually to the issues you brought up: - Demo video: this is what I get for counting my chickens before they hatch! :) I had a script and had started capturing footage for the in-depth tutorial, but life got the better of me, and I was never able to finish. The footage and script are lost to time, but they eventually became the demo I used for my Unite talk, linked in the description above. Specifically, here's a link to that portion, which I've also updated in the description on the overview video on YouTube https://www.youtube.com/watch?v=b033hYK5chw&t=330s - Git integration: As I said above this is still on my to-do list. The fact of the matter is that I originally wrote those scripts/guides back in 2014/2015 and things have changed a bit since then. Thanks for noting the chmod step--I'll add that do the documentation after testing the workflow myself. Personally, even when I had the git integration workflow, it was just too much of a pain to get it set up on all my machines for all my projects, so I just fell back to manually grabbing different versions of the files I need to merge. Ultimately, I want to address all these issues, so it's easier to set up the integration than to work around it. Given the new landscape of git tools and configuration options, I wouldn't be surprised if the issues I hit 6 years ago have workarounds today. The hardest part here is that there are a ton of permutations for git workflows. Some people exclusively use command-line, some use a GUI like Fork, SourceTree, GitKraken, TortoiseGit, etc., and then you have to multiply all those permutations x2 to cover MacOS and Windows (or even x3 if you care about Linux!). The current state of things is that you have the puzzle pieces and you are meant to know how to integrate a custom merge tool into your current workflow. I agree this isn't ideal, but it's the best I was able to come up with at the time. - "Coming soon" was probably a bad choice of language for this stuff. I sincerely did/do plan to work on these improvements, but what's the phrase? The path to hell is paved with good intentions? Let's just say I've learned to promise a little bit less. I left some of these promises in the documentation with my latest update, but if I can't figure out the VCS stuff soon, I'll probably push another update that just removes the claim about VCS integration. - Custom Layouts: Unfortunately, I'm pretty sure this is just a Unity bug. I've noticed this happens with pretty much any custom EditorWindow across the various projects I've worked on. I believe the issue occurs when you open the project with a different version than what you last used to save the layout, or maybe when making changes outside of Unity like checking out from Version Control, custom Windows (and even some built-in windows, in my experience) will fail to load. Otherwise, I'm not sure what could be causing the issue. I just did a quick test with the test projects I've been using to validate the latest release. If I add the ObjectMerge window to a custom layout in 2018.4, 2019.4, and 2022.1 and close the Editor, ObjectMerge is right back where I put it when I open the project back up. Saving a custom "Merge" layout also seems to work for me in this simple isolation use case. I would suggest that you report a bug to Unity using the bug reporter. There's nothing particularly special about the UniMerge windows, so I can't think of anything I'm doing that would cause this issue in particular. - Red rows missing foldout arrows: This is actually by design. I'll admit that the interface is a little bit confusing, but I couldn't think of a better way to smash together component properties and GameObject hierarchies. I'm pretty sure what you are seeing here is a conflicted GameObject row which has no children, but does have components which have differences. You can click the "+" button on the right side of the view to expand the components for this GameObject row, which should expand the component rows, which themselves should have foldout arrows to expand their properties, where the differences lie. The Expand Differences button is your friend here. It should expand everything you need to find the source of all the redness. If you've tried all of that, and you still see red rows with no children or collapsed components, that's a bug. I'd love to know how to reproduce this specific issue so I can work out a fix. - Detecting GameObjects that have become prefabs: To be honest, this just isn't a situation I've encountered in my own use of the tool, so it's not something I thought to check for. I decided to prioritize the comparison filters for this update, but once I get through the VCS stuff, I should be able to throw this into the next update. - Comparison filters: I've saved the best for last. I totally overhauled this UI for 1.14! The flags fields seemed like a good idea at the time, but it's definitely been something I've been meaning to address. The new UI lets you search for types to filter out, and they show up below as clickable buttons which will remove that type from the filter list when clicked. Hopefully this is more user friendly and encourages use of this feature. - "Expand" but not "Collapse": What do you mean by this? Are you referring to the Expand Differences button? I suppose I could include a "collapse all" but you can also do this by alt-clicking on the foldout for the root object row, or using the arrow keys, as described in the documentation. - Child order: The documentation mentions this, but children are re-ordered by design. The tool uses GameObject names to decide whether one object corresponds to its "sibling" in the other hierarchy. If GameObjects are re-ordered, we still match them back up by name, which is easiest handled by just sorting the rows by name, lexicographically. The underlying sibling order of the Transforms themselves isn't changed, it's just how they are presented in the merge view. I'm open to better ways to handle this, or even an option to respect sibling order, but this has been a good compromise so far in my experience. -General UX: I'll admit that the UI could use improvement, but in my opinion, it's a good compromise in terms of UX complexity and implementation complexity. If I were to do things differently, I would have probably split the display of GameObject hierarchies and Component properties into different views, but at this point that would be a major rewrite/overhaul, and I haven't been able to take the time to do this. I've given some thought to a "version 2" of the tool but I haven't had the "eureka" moment about the best way to present everything. A big ask from other users has been 3-way merge, which would be a major priority for the rewrite, as well. In summary: a software developer's work is never done. I'm still committed to supporting and maintaining UniMerge, but I can't spend unlimited time working on it. I really do appreciate detailed feedback like this. Breaking this down issue-by-issue and tackling them one by one is the best way to improve.

Good catch. I'll add support for this in the next update.

Hi there! Sorry for the delayed response, but I wanted to make sure I double-checked before replying. I submitted the package from version 2017.1.0 along with a number of other versions. I also pulled the version from the store into 2017.1 into a fresh project made with that version of the editor. What platform are you using? Could it be something else in your project that is conflicting with the UniMerge scripts? Please feel free to reach out to us via the support e-mail if you are still having trouble.