Question Update (re-save) prefabs in the project for the new Unity

Hello
When migrating to the new Unity, I encountered an inconvenience when changing prefabs. When I change something in my prefab, in addition to the changes I need, I see many more changes that Unity makes, for example, adding new fields (even empty ones), shifting lines in the prefab file, updating the prefabversion, etc. I would like to see only the changes that I made so that I can check that everything is in order before committing.
How can I update (re-save) all the prefabs in the project so that only my changes are visible in the future?

 

I always accomplish this by going into the Project Settings -> Editor and changing serialization to Force Binary, then waiting, then changing it back to Force Text.

I'm not sure if that option remains in the latest and greatest versions of Unity however... maybe?

CAUTION: it touches EVERYTHING, so make sure you really really really are confident on this upgrade to Unity!

Here's more on upgrades before you go down this one-way street:

ISSUES RELATED TO UPGRADING PROJECTS (eg, changing to a higher Unity version)

Upgrading to a later version of Unity is a one-way process. Any project that has been updated should NEVER be reverted to an earlier version of Unity because this is expressly not supported by Unity. Doing so exposes your project to internal inconsistencies and breakage that may actually be impossible to repair.

If you want to upgrade to a newer version of Unity, do not even consider it until you have placed your project fully under proper source control. This goes double or triple for non-LTS (Tech Stream) versions of Unity3D, which can be extremely unstable compared with LTS.

Once you have source-controlled your project then you may attempt a Unity upgrade. Immediately after any attempted upgrade you should try to view as much of your project as possible, with a mind to looking for broken animations or materials or any other scripting errors or runtime issues.

After an upgrade you should ALWAYS build to all targets you contemplate supporting: iOS and Android can be particularly finicky, and of course any third party libraries you use must also "play nice" with the new version of Unity. Since you didn't write the third party library, it is up to you to vet it against the new version to make sure it still works.

If there are issues in your testing after upgrading Unity, ABANDON the upgrade, revert your project in source control and be back where you were pre-upgrade with the earlier version of Unity.

Obviously the less you test after the upgrade the more chance you will have of an undiscovered critical issue.

This risk of upgrading is entirely on you and must be considered whenever you contemplate a Unity version upgrade.

Do not upgrade "just for fun" or you may become very unhappy.

 

In modern source control systems such as git and Mercurial, this is functionally identical (and yet FAR more error prone plus it breaks your revision history!) to simply forcing Unity to reserialize all assets and then committing the changes.

Every commit of every file is a completely new version of the file. "Renames" or "modifications" are simply the delta that it took to get from one version to the next. Otherwise, each version is its own blob. Removing and re-adding is simply wasting your clicks and (almost certainly) breaking your file revision history.

The point of version control is to provide a pure semantically-meaningful history. Deleting and re-adding is creating lies about the actual past intent of the commits.

 

Yeah, I would never recommend yanking and then reinserting files from version control, traceability and history is the raison d'etre for a VCS.

However, I would definitely focus the "migration" task to a single machine, on a fresh branch, allowing carte blanche to update all files if the engine needs to make updates. Of course as the engine goes through a version bump, all the serialization for assets potentially need a version bump too. If the engine does a "lazy migration" withholding minor changes until the asset needs to be saved, now is the time to capture the engine's migration changes by forcing a full reserialization.

Once the core changes have been made and the project can load, commit those and then begin the manual migration efforts to fix/update issues found due to the version bump. Keep working in the new branch until you have decided to accept the new version of Unity, or kill the branch and go back to your earlier version of Unity.