Question

I’m seriously about to stop coding and become a carpenter. This problem has had me stressed out for quite some time now and there doesn’t seem to be any clear solution, other than forcing non-windows machines to use the file permissions windows seems to inflict.

Let’s begin with the scenario. I have 2 development machines, one running Windows7, the other Mac OSX. They both are using Eclipse and EGit, and both have cloned the same project from a remote repo. That’s where the similarities end, because my windows machine has a nasty habit of retaining a file mode of 644 (r-xr–r–) on its local repo, while the mode on the Mac defaults to a cool 775 (rwxrwxr–x).

So the problem’s obviously the file permissions – GIT reports there are files that have changed due to differences in file modes and not actual content. The solution seemed obvious, run the following commands:

 git config core.filemode false
 git config --global core.filemode false

…which worked like a charm, except when committing and merging resolved conflicts.

For example, say files A, B and C exist on both the Windows and Mac repos. Next, let’s change the file mode for these 3 files on the Mac machine so that the developer can edit them. Now change some of the contents in file A. Because we’re ignoring the file modes (thanks to the commands above) only file A will be committed and pushed, ready for the Windows machine to fetch, merge and enjoy…

Now, let’s edit file A again on the Mac and on the Windows machines, effectively causing a potential conflict, and let the Windows machine commit and push file A first. Then, when the Mac user commits their changes to file A and fetches the latest changes from the remote repo, a conflict is obviously created.

After resolving the conflict on the Mac machine and adding file A back to their local repo, committing that merge includes the previously ignored files B and C, and thus highlighting my problem! Why are the previously ignored files being included in this merge commit? This doesn’t seem to be a Mac / Windows problem exclusively, as this problem can be recreated both ways…

This probably wouldn’t matter if there were only 3 files, but this project I’m referring to includes thousands, and all these up and down push and pulls are insane. Am I missing something really obvious? Any help will be greatly appreciated!

Answer 1

So after a long and often frustrating run with trying to get Windows and Mac OS machines to like each other when comparing notes and changes over Git, it seems to just be the functionality of Git itself that’s driven me mad, and a better understanding of how to better use Git seems to be the final answer.

Originally, I wanted to know how to continue ignoring file-mode changes (which Windows seemed to love updating with its own idea of what permissions and modes should be) while I was resolving conflicts created from updates to the files from someone else. Short answer: you can’t. It’s just the way Git works.

So how would you deal with this situation when it came up? Short answer again: use branching.

In my original way of using Git, I was continually working on my master branch on my local repo – bad idea already – so all my work would be committed there and all conflict resolution would need to be handled there too, forcing all files to be compared again and all permissions and file modes to come into question.

With branching, you work on another branch, commit to that branch, pull updates to your master branch, and merge you other branch with your master branch after that. Suddenly no more conflicts on the master from the remote repo, and you’re winning!

Commands to do this (creating a branch from currently selected branch):

git branch newbranch

To checkout your new branch:

git checkout newbranch

To merge your new branch with your master branch (after you’ve committed to your newbranch, switch to the master first):

git checkout master
git merge newbranch

Hope this helps someone! -:)