Re: Trouble with Gaia binary files

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.

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.
-- 
brian m. carlson (they/them or he/him)
Toronto, Ontario, CA

Attachment: signature.asc
Description: PGP signature


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux