Why does merging from a particular GitHub repository into a local Git repository result in uncommitted changes in the local repository?

Question

I have 2 GitHub repos, let's call them GH1 and GH2, and 2 corresponding local repos, let's call them LR1 and LR2 that have them as remotes. For clarity, here is the local repo to remote repo mapping:
LR1 ---> GH1
LR2 ---> GH2

I manually upload (and commit) the same file, let's call it A.jpg, to both GitHub repos using the GitHub web UI. I get different results when I try to merge from the remotes back down to my local repos.

I use git on the command line for the purposes of this problem.

One of local repos (LR1) behaves as I would expect: git fetch gets the change from the remote but doesn't merge it. git merge merges A.jpg and fast-forwards the local repo. git status shows that there is "nothing to commit, working directory clean"

The other one (LR2) behaves differently than I would expect: git fetch gets the change from the remote but doesn't merge it. git merge merges A.jpg and fast-forwards the local repo. git status shows that A.jpg is modified and is an uncommitted change.

git pull behaves the same way, with respect to the 2 local repos, but for the purposes of breaking this problem down, I thought I would explicitly call out the 2 commands (git fetch and git merge) that do the same thing as a pull.

I assume that I have the 2 local git repos configured differently and that is causing the issue. What would cause this behaviour?

Answer 1

I'll share my understanding of the problem and how I resolved this, thanks to the helpful comments on this post.

The problem has everything to do with the SMB mount, file permissions, and git configuration. The problem is that when I use git to sync from the remote to my local repo and a new file needs to be created by git in my local repo, git is creating a new file using its default setting for permissions (644) and the SMB mount, under which the local repo existed, has no setting configured for file mode so it was using its default (755). The end result was that git thought it was creating a file with 644 permissions but as soon it got created it assumed 755 permissions because that's what the mount forces for new files...and so git thought that the file it just created had changed and deemed it as an uncommitted locally changed file. This was resolved by a few changes:

• Changed the SMB mount in /etc/fstab to include the file mode (file_mode=0644) that matches what git wants
• Once I did this and unmounted/remounted it, all of the files in my local repo now show as uncommitted local changes because the permission (644) is different than what my local repo is aware of and my git settings are sensitive to that. I verified it by checking the git settings

git config --get core.fileMode

• This was resolved by changing the git configuration for the repository. In the .git folder in the local repo root, I edited the config file so that filemode = false.
• Once I did this, git status shows that there are no uncommitted local changes.

This git documentation explains well how this could happen, which is very close to what happened to me (i.e. cloned remote repo to local repo on local disk before it was on SMB mount and then eventually moved the local repo to an SMB mount)

Now, new files added to the GitHub repo and then pulled down to the local repo no longer show up as locally uncommited changes. Rather, they are merged properly and transparently.