Undo local changes in git-lfs-CodePudding

I have a git-lfs repo with local changes and I want to discard them. I tried the following command without success:

git checkout file

git checkout -- file

git lfs checkout file

git reset --hard

What command should I use?

Thanks!

EDIT:

Viewing the modifications with gitk revealed that r/w attributes were changed for all files. Contents are identical.

-------------------- .gitattributes --------------------
old mode 100644
new mode 100755

Also tried the suggestions mentioned here without success: Unstaged changes left after git reset --hard

CodePudding user response：

TL;DR

You probably manually set core.fileMode to true. Set it back to false.

Long

Viewing the modifications with gitk revealed that r/w attributes were changed for all files. Contents are identical.
-------------------- .gitattributes --------------------
old mode 100644
new mode 100755

The git reset --hard will have attempted to change the mode as well. Apparently this attempt failed, perhaps without any errors being reported.

This behavior is commonly seen on DOS/Windows-style file systems, where x and -x modes are simply not supported. Some adapters report all files as mode 644 (rw-r--r--) and some adapters report all files as mode 755 (rwx-r-xr-x); it looks like you have the second kind.

Git normally detects and adjusts itself for these kinds of file systems: at the time the repository is created, Git does a few "create a file and change its mode" tests. If the mode changes from x to -x and/or vice versa are obeyed, Git believes that the OS and file system do support modes, and it therefore sets a configuration setting:

core.fileMode true

If these changes are not obeyed, Git believes that the OS and file system do not support modes, and it therefore sets the opposite setting:

core.fileMode false

Note that this setting, core.filemode (sometimes in mixed camelCase and sometimes all lowercase: Git is case-insensitive here, though not elsewhere), tells Git how your system works. It does not control the system, it simply reports the earlier observation.

If you, manually, change this variable, you're telling Git that you have replaced your operating system and/or file system, and it now works the other way. If you did in fact replace your OS and/or file system and it does work the other way, your new setting is correct. But if not, you have now lied to Git.

Or, you might take your entire .git repository and working tree and move them to a new file system. When you do that, depending on your particular OS and file systems, it's possible that the old core.fileMode setting is now inaccurate. Git won't know this—Git will believe the old setting. By moving the files, you have, in effect, lied to Git, though in this case you probably didn't have any reason to suspect something like that.

In both cases, the fix is to correct the lie: inform Git how the file system really works, by setting core.fileMode to false or true appropriately. Once it's set correctly, Git will know whether to assume the attributes settings it sees are valid (core.fileMode true) and therefore you'll see this kind of change, or not (core.fileMode false) and therefore you won't see this kind of change.