RE: Trouble with Gaia binary files
On Monday, July 1, 2024 4:15 PM, brian m. carlson wrote:
Show 29 quoted lines
>On 2024-07-01 at 15:34:04, Alec Sanders wrote:
>> Hello,
>>
>> I am running into an issue with Git and Gaia files This error persists
>> when I perform a git checkout or git merge.
>> The error is as follows
>>
>> error: Your local changes to the following files would be overwritten
>> by checkout:
>>
>> *Insert filepath here*
>> Filepath directs the user to the project folder and within it, Assets,
>> Gaia User Data, Sessions, ... , Terrain data, etc
>>
>> Please commit your changes or stash them before you switch branches.
>> aborting
>
>This message isn't particular to any given type of file. What it means is that your
>files are modified in the working tree and the operation you want to perform (a
>checkout or a merge) will modify the working tree. Because doing that operation
>would destroy data, Git asks you to do something specific to make your working
>tree clean before you can do that operation.
>
>I'm not familiar with Gaia, but in the case that you're using Git LFS, this could be
>caused by using Git LFS incorrectly, whether by you or someone else, that can lead
>to files being perpetually marked modified.
>If a file is tracked as a Git LFS file (that is, the file type is listed as `filter=lfs` in
>`.gitattributes`), but someone has checked in the file without installing or enabling
>Git LFS (that is, as a regular file), then the file will end up always modified.
I have seen this situation resulting from security attribute mismatches under Windows. If the Gaia generated files are executable and core.filemode=true and/or the files are not added with --chmod=+x, this can be persistent. This sometimes gets past git status in a Cygwin shell but shows up as a difference in ECLIPSE.
Show 16 quoted lines
>That happens because if the file is updated in the working tree, Git tries to run the
>clean filter to turn it into a pointer file, and since that differs from what's in the
>repository (which is the full file), Git marks it as modified. Attempting to check out
>or reset the file causes the same thing to occur, resulting in the same situation.
>
>In any event, if you _do_ want to keep the changes, you should run `git stash` to
>stash the changes, and then checkout or merge. If you _don't_ want the changes
>and you are really certain you want to destroy all of them, you can run `git reset --
>hard` (this really does destroy them, so be careful).
>
>If you have the Git LFS problem I mentioned above, `git reset --hard` will not fix the
>problem. In such a case, you will need to do `git add --renormalize .` and then `git
>commit` to fix the state of the branch.
>You'll need to do this to every affected branch. You can also run `git lfs fsck --
>pointers BASE..HEAD` (substituting `BASE` and `HEAD`) in your CI system, which will
>exit nonzero and print an error if someone does this again.