HUGE ISSUE - Switching Git branches corrupting assets! Have to reimport all to fix!

Since updating to Unity 2019.3 switching branches in Git corrupts assets. This corruption seems to be in Unity's library/caches since the corruptions don't show in git and reimporting all resolves the issue but it takes ~30 mins for our project.

Is anyone else experiencing this issue?

We have a team of people experiencing this issue. It seems as though closing Unity before switching branches reduces the likeliness of it happening.

What do I mean by corrupts? Various scripts and prefabs which changed in the branches I'm switching between will need to be reimported but knowing which ones isn't always possible. Sometimes components lose references which we won't discover until we play that part of the game. These lost references don't show up in Git as changes so they can't simply be reverted, this is also something of a relief because we can't commit the corruptions. These corruptions could however unknowingly end up in a production build

Reimporting frequently feels like...

 

I guess no one else is experiencing this issue

 

Are you versioning the library folder?

 

@bobisgod234 Thanks for trying to help, but we're definitely not version controlling the library folder.

 

It's not just you. We have exactly the same issue. Note that you don't always have to reimport everything. Sometimes it helps to reimport just the affected asset.

 

@meta-ben Sorry to hear you're having trouble

Are you also using Asset Pipeline v2?

Our problem is if something has corrupted and we don't immediately notice. What if we do build and release it with that corrupt asset. We do testing but sometimes bugs survive.

We've updated to Unity 2019.4.6f1 and are still experiencing the same issue.

 

We've updated to Unity 2019.4.8f1 and are still experiencing the same issue

 

Yeah, same here. That and we get random changes in (untouched) prefabs where data just moved to different locations in the file. Really annoying

 

We've updated to Unity 2019.4.14f1 and are still experiencing the same issue

 

Are you keeping Unity minimized during source control operations?

 

@KokkuHub yes and we're closing Unity when doing anything other than committing or pulling changes into the current branch.

 

We have been living with this issue for several months. This bug is making us very hard to work in a medium size team with different branches because we get some prefabs with missing references after switching to a different branch.

 

We've updated to Unity 2020.3.10f1 and are still experiencing the same issue

 

Still happens all the time to me as well. Please Unity, fix this, it makes development a struggle when version control isn't even viable. Honestly, it's really embarrassing...

 

We haven't been able to able to reliably reproduce the issue

 

Btw it's still happening in Unity 2020.3.13f1

For those who are experiencing this issue, select all the prefabs in your project and re-import them. I've been told by my coworkers that it generally resolves the issue when it happens and It's much quicker than reimporting your whole project.

 

@Tautvydas-Zilys - Ok so here is an example of the issue.

We have a prefab that is referencing an asset on disk.

On my computer the prefab has the wrong GUID for the asset it is referencing but in the inspector the reference remain intact. There are no changes to assets present in source control.

On another computer, in the inspector, the prefabs reference to the asset doensn't exist. There are no changes to assets present in source control.

The asset had recently been renamed and changes made to it.

Edit: I took a screenshot. On the left is the prefab, in the center is the editor inspector of the same prefab, on the right is the asset referenced in the _moreProgress field on the prefab. You can see that even though the reference is present in the editor inspector the prefab has the wrong GUID saved for the _moreProgress field.

 

Definately via Unity.

 

I see this issue occur regularly here too, but don't have a step-by-step list how to reproduce it. It's not related to renaming assets as far as I can tell, because I see it happening for prefab modifications only too.

My workaround is to reimport all prefabs when switching branches.

I believe that's related to Library cache too. Using Unity 2019.4.20f1 with Asset Pipeline v1, btw.

 

Having the same problem here (2019.4.21). It doesn't happen on every branch change and the affected prefabs vary. Exiting Unity and deleting the Library, obj and Temp folders resolves it. But that is time consuming.

It wastes a lot of development time looking for real bugs vs these ghost bugs that are resolved by reimporting everything.

This also isn't the only thread about this https://forum.unity.com/threads/swi...-missing-references-on-nested-prefabs.836140/ Don't know how many more there are around. But these were the first two googling for the problem.

 

Happens here too regularly. We use a lot of branches for developing new features prior merging them into master and prefab corruptions usually happen with UI parts (maybe it's because the ui part of our game is most frequently changing). It's really hard to work this way. 2019.4.30f here.

As previously was said - the references can be even OK in the editor upon opening the prefab, but the real guids can be wrong on hidden part, thus leading to the errors we don't see during Edit Time and only visible on runtime or in builds.

Even precautions like closing Unity completely and cleaning up all uncommitted changes before switching branches doesn't help sometimes.

 

Has anyone come up with reliable reproduction steps and submitted a bug report that we can throw some votes behind? I cant come up with reliable reproduction steps .

We're probably going to change our workflow to minimize branch usage because this problem wastes a lot of time. But it would be a lot better to see the problem fixed.

 

A workaround to this problem is to just have different project folders for different branches.

 

Usually in such cases we just reimport the fault prefabs (like if ui breaks we reimport whole UI prefabs folder) - helps in 90% cases. Does not take much time, but some nighty builds could be wasted...

 

We have the same problem. It is a HUGE problem for us as well, because as you say, these error can easily end up in production builds.
When it does happen, re-importing prefabs & scriptableobjects fixes it.

BTW: Using Unity 2020.3.19f1

 

Will just add that this appears to happen also in later versions of Unity, I reproduced it in Unity 2021.2.13f1. In my example it was a reference on a nested prefab.

 

Sooo I think Unity is now (2020.3.32f1) detecting when this problem occurs. It logs out the following...

The asset at ... has been scheduled for reimport during the Refresh loop and Loading of it has been attempted.
Doing this can lead to the AssetDatabase returning two versions of the same asset.
Please ensure that code which attempts to reimport this asset does not run while the editor is Refreshing.
You can do so by checking the value of EditorApplication.isUpdating​

Maybe we're doing something in OnValidate that is causing the issue. We need to find some time to investigate.

 

I have reliably reproduced it and made very simple repro project. I has been submitted as a bug through Unity and has the case number 1426451. It is reproducible in at least both 2020.3.19f1 and 2020.3.34f1.

It hasn't been processed so that it is visible in the issue tracker. I assume that it is because it has to be manually processed somehow.

BTW, It was submitted May 9th.

 

Unity is notoriously neglectful with calling

fflush(3)

when it changes files.

To see this, open ANY version of Unity from the past decade.

Change a setting in a material, such as the tiling or offset.

Press PLAY and note that the change has taken effect.

Now go look at your source control diff and note that there is no change.

For this reason, I always suggest beginners exit Unity before changing branches or doing any source control work.

If you are adequately disciplined then doing a File -> Save Project should commit ALL pending changes to disk, enabling a full commit and/or change of branch.

You should NEVER switch back to Unity until the entire branch change has finished and no more files are changed, otherwise Unity will get into this weird half-updated state while the source control is still updating files. This is bad.

However, recent versions of Unity are far twitchier as far as watching for changes in directories with auto-refresh, and they will instantly begin reimporting as soon as one file changes, even before you bring focus back.

Therefore, now once again it is still safer to always close Unity, change your branches, then reopen Unity.

 

We are also facing the same problem in unity version 2020.3.31f1.

@Lars-Blaabjerg
Have you got any update from unity team? or found any solution other than re-importing?

Thanks in advance.

 

A little mixed actually, because of a mixup, there ended up being two reports.

The first to be processed had a lot of back and forth and ended basically by the guy telling me that changing files outside unity is not supported and we just have to live with it (which is a bit ridiculous tbh).

I had forgotten about the other one, when I suddenly got a notice saying they had reproduced it and had moved it on further in the system. That one is now publicly available to be voted on now: https://issuetracker.unity3d.com/is...ost-when-switching-between-branches-using-git

 

Voted! If they closed the first one as you say that is an extraordinarily terrible attitude towards developers. Saying "not our problem" to one of the most popular version control systems in the world??