6

There are 2 machines, A and B. And there are 2 branches, p16 and c2.

A has an ext3 filesystem, but on B the archive lives on a truecrypt drive with vfat, mount shows rw,uid=1000,gid=1000,umask=077

A has linked the directory tree of B into its directory tree using sshfs and then A pushed into B's p16 using the filesystem.

Now there are some permission problems:

B$ git status
# On branch p16
nothing to commit (working directory clean)
B$ git checkout c2
Switched to branch 'c2'
B$ git checkout p16
error: You have local changes to 'help.txt'; cannot switch branches.

git diff shows me a changed mode for all files now:

B$git diff
diff --git a/help.txtt b/help.txt
old mode 100644
new mode 100755
diff --git a/169.txt b/169.txt
old mode 100644
new mode 100755
... 
(a list with all files having their mode changed follows)
...

I guess the problem is that the local filesystem is a vfat truecrypt container and the filesystem does not allow the permissions that the other machine expects.

Any ideas how I can better link the 2 machines with different filesystems?

mit
  • 11,083
  • 11
  • 50
  • 74
  • Just a guess, but does branch p16 have a .gitignore that is ignoring the the files with changes? – coreyward Mar 24 '11 at 20:32
  • p16 has a gitignore with 2 lines, see updated question – mit Mar 24 '11 at 20:33
  • 1
    Are you on Windows? It lacks an `x` bit which leads to a lot of pain like you describe. – Ben Jackson Mar 24 '11 at 20:37
  • You pushed into a non-bare repository? – Cascabel Mar 24 '11 at 20:37
  • 5
    Your OS is probably doing something funny with file permissions; try setting `filemode=false` in .git/config which will tell git to ignore the executable bit for files it's tracking. – user229044 Mar 24 '11 at 20:37
  • @mit: Ah, okay, cool. I asked because pushing into the checked-out branch will leave you with your working tree in the old state, and the index in the new state, appearing to cause a diff. – Cascabel Mar 24 '11 at 20:49
  • @Jefromi I went into that trap before, that's why I introduced seperate branches for both machines – mit Mar 24 '11 at 20:53
  • [How do I remove files saying “old mode 100755 new mode 100644” from unstaged changes in Git?](https://stackoverflow.com/q/1257592/6521116) – LF00 Aug 09 '17 at 05:32

2 Answers2

16

Such problems using git can occur, if the file permissions of the operating system are not functioning as they should in that location. For example, when foreign filesystems are mounted.

The solution was pointed out by meagar in his comment on the question above:

Just make sure you have (within the [core] section) a line 

filemode=false

in .git/config which will tell git to ignore the executable bit for files it's tracking.

Another way of doing the same thing would be to go to the root directory of the git repo in the terminal and type:

git config core.filemode false

Note that changing this setting is occasionally necessary, but otherwise it is better to keep the default behaviour. It's important in many cases for git to track file permissions correctly, so your project can work as it should.

mit
  • 11,083
  • 11
  • 50
  • 74
  • 1
    This seems dangerous. This is also definitely out of my realm of knowledge. What are the possible repercussions of doing this in git? – dudewad Jan 10 '17 at 05:51
3

My Ubuntu installation was corrupted and I had to do a complete install of 22.04 (Jammy Jellyfish).

I backed up a large number of git repos (projects of all types, C#, HTML/JS, etc.) and then restored them. I discovered that many of the files were now set to 755 (executable) where they had been 644.

old mode 100644
new mode 100755

Because nothing else had changed and these files were improperly set to exe also. I simply checked out the original files again with the following command:

$ git checkout .

This checked out the main branch code again and the filemodes were restored to 644.

raddevus
  • 8,142
  • 7
  • 66
  • 87
  • 1
    Same. When I changed my Mac laptops, I backed up my git projects in an external SSD using `rsync`. Restored them to the new laptop and ended up having numerous staged files. `git checkout .` fixed it. – PsyGik Jan 27 '23 at 18:19