level doesn't appear after restore

[tahakinn]

Hi,

I pull an outdated level from my friend, and then I restored the level so that my changes would not be lost, but the level was lost. The reason for doing this is that he made the interaction update of the project, and I made the environment, but he shared the interaction update with me without having the environment level that I had. He has an outdated level of the environment.

[KalleOlaviNiemitalo]

Did both of you edit the same file, or different files?

[tahakinn]

Did both of you edit the same file, or different files?

same file

[chrisd8088]

Hey, I'm sorry you're having trouble. I take it you're using Git LFS in some way, but I'm not sure how we can help as you haven't provided any details. If you can supply us with the series of Git commands you used and explain what you expected to see versus what you saw, and also the output of git lfs env, that might be a starting point.

[tahakinn]

Hey, I'm sorry you're having trouble. I take it you're using Git LFS in some way, but I'm not sure how we can help as you haven't provided any details. If you can supply us with the series of Git commands you used and explain what you expected to see versus what you saw, and also the output of git lfs env, that might be a starting point.

Hey, thank you for your answer. I created a repository using this video youtu.be/n3x1fErlmYA?si=MFzRPstIxT_KpgnU The commands I use are -git lfs track ".uasset"
-git lfs track ".umap". I am doing the environmental design of the project and my friend is coding it. He doesn't have the current environment I have. When he pushed it to me, some files conflicted and the current level I made was lost. I hope I explained myself sufficiently. Thank you again.

[KalleOlaviNiemitalo]

Had you committed the changes that you made? If you had, then they may still be reachable from the Git commit history or from a reflog.

You could also try examining the files in subdirectories of .git/lfs/objects/; some of them may be the lost file, even if it is no longer reachable from Git. The timestamps of the files may help you find the correct one.

[bk2204]

If there's a conflict, then the file in your working tree probably has a pointer with conflict markers in it, which you can see if you edit it in a text editor. You'll need to resolve that conflict by choosing one set of lines versus the other.

For example, it might look something like this:

version https://git-lfs.github.com/spec/v1
<<<<<<< HEAD
oid sha256:8807953138274f7bd417673cde9848823b1fe720b5ed7b01f8fa00681a456da0
||||||| 0966ccd
oid sha256:edeaaff3f1774ad2888673770c6d64097e391bc362d7d6fb34982ddf0efd18cb
=======
oid sha256:da1464fd7ceaf38ff56043bc1774af4fb5cb83ef5358981d78de0b8be5a6fbcb
>>>>>>> other
size 4

The version that's under HEAD is going to be the version that's in your current branch. The version above other here is the version that's in the branch you're merging into yours (in my case, this branch is called other, hence why it says other). Note that you might also have a conflict over the size line.

You're going to need to resolve this such that you choose exactly one of these options (and you must pick the same oid and size line from the same group) and remove the conflict marker lines. For example, if you want the version in your branch, then you'd resolve it to look like this:

version https://git-lfs.github.com/spec/v1
oid sha256:8807953138274f7bd417673cde9848823b1fe720b5ed7b01f8fa00681a456da0
size 4

Once you've done that, you can save and run git lfs pull and you should get the level back in your tree. Then, save and commit the changes to resolve the conflict.

Note that unless you have a custom merge driver, you can't merge the two versions of the level together, since they're binary files. Only a custom merge driver specifically built for that file type can do that.