Help with git-lfs and terrains

Hi. I'm using git lfs to source control my project. In the .gitignore file, I use this setting:

Code (CSharp):

1. *.asset merge=unityyamlmerge eol=lf

My project has force Text as asset serialization. This works for every .asset file except the terrains, because they always serialize as binary. This breaks something inside git-lfs, making the terrains unreadable in cloned projects.

Has anyone else solved this problem? I'm not so proficient in git, but I can't see a way to make git recognize betweet .asset for terrains and .asset for everything else. Currently the only way I have to solve this is to manually pass the terrain .asset files to my team members.

 

bump

We've had a nightmare with terrains and LFS, but we had the same problems back when we used Collab (shudder)

Have you had any progress on this?

 

We switched to meshes for this particular project due to poor performance and this problem.

 

Just hit this issue a couple of days ago. Our "solution" was to add

Code (CSharp):

1. *.terrain.asset binary

above

Code (CSharp):

1. *.asset merge=unityyamlmerge eol=lf

in the .gitattributes file.

We then renamed our terrain files to use .terrain.asset instead of just .asset.

Apparently, you might also have to do this for lighting data and navmesh data files since they don't use the YAML file format either.

The REAL solution would be for Unity to NOT give these files .asset extensions; but good luck with that one...

 

I answered in the other thread too, gitattributes favors the latter rule among the ones you give that match a single file.
If you can rename the assets without issue, then create a rule for a specific naming convention like @DefinityRelin does.
If you can't (e.g. LightingData.asset), just create a second rule further down the file where you give:
```
LightingData.asset binary
```
If you still have issues, look into git check-attr command which tells you what attributes a given file has and also check specifically for text like so:
```
git check-attr text <filename>
```
if it tells you that text is specified and the value is unset, that means the last rule to apply to this file specifically states "-text" or perhaps uses "text=auto" and git has recognized it as a binary file.

If `git check-attr text <filename>` returns "text=unspecified", git checks to see core.autocrlf property in the repository configuration for guidance. Usually by default autocrlf is true, so git will think of it as text. if you've explicitly set autocrlf to false then it will do nothing (won't try diffing it). So it's best if you are very specific in gitattributes for special cases. And if not sure, use git check-attr to debug.