Git Shows Random Files Changed on MAC Nfs Filesystem

git shows random files changed on Mac NFS filesystem

Maybe unsynchronized time between the servers and workstations makes the modification times of the files unreliable. Does setting of core.trustctime help? (it is true by default).
There is an even heavier setting: core.ignoreStat to ignore complete stat(2) information in the change detection code.

Git refusing to merge because of changes to an unchanged file

Thanks to Andrew Myers' comment on my initial question, I discovered setting core.trustctime to false solved the problem.

git config core.trustctime false

Something about mismatching inode change times. I'm guessing this is because the repo is sitting on a fileshare on a machine with a different file system from the one I'm using.

Thanks for all the suggestions!

GitBucket: error: Your local changes to the following files would be overwritten by merge

While looking around i tried the following that seemed to fix my issue at the time.

While on the branch i wrote.

   git reset --hard

What does 'git commit' mean when it says 'create mode ...' on stdout?

For more information about Git's mode, see this answer.

Git's ability to store file metadata is limited to a simple subset of information to allow Git to track some basic file system changes allowing Git to track relevant changes for source code management; such as whether a file has been modified and whether a file is a regular file or an executable file.

Git does not try to implement any notion of a file system, leaving file system routines to an actual file system implementation. This makes good sense to allow Git to work equally whether on a FAT32, NTFS, EXT3, XFS, NFS, etc. file system running on Linux, MacOS, Windows, etc.

String replacement with a 'batch file' ran with sh?

The 'sed' utility, the stream editor, is the shell tool to do this. You could do something like the following to do what you asked, join file1 and file2, change all occurances of x to y and then run the commands with the bash shell:

cat file1 file2 | sed -e 's/x/y/g' | bash

What does 'stale file handle' in Linux mean?

When the directory is deleted, the inode for that directory (and the inodes for its contents) are recycled. The pointer your shell has to that directory's inode (and its contents's inodes) are now no longer valid. When the directory is restored from backup, the old inodes are not (necessarily) reused; the directory and its contents are stored on random inodes. The only thing that stays the same is that the parent directory reuses the same name for the restored directory (because you told it to).

Now if you attempt to access the contents of the directory that your original shell is still pointing to, it communicates that request to the file system as a request for the original inode, which has since been recycled (and may even be in use for something entirely different now). So you get a stale file handle message because you asked for some nonexistent data.

When you perform a cd operation, the shell reevaluates the inode location of whatever destination you give it. Now that your shell knows the new inode for the directory (and the new inodes for its contents), future requests for its contents will be valid.

---

Related Topics