I have a git repository (and working directory) that is stored in my Dropbox so I can move back and forth between computers without having to commit or stash (read: without any effort at all). This is working great except for one minor annoyance that is becoming a major annoyance.
Every so often, I'll leave one computer in a fully committed state only to pick up on the other computer and find that a git status
reports changes. Inevitably, those changes are related to permissions. What I'm not sure about is why? I assumed that it might be related to how Dropbox writes files on sync'd computers, but the umask
on both systems is set to 0002. I would assume that value dictates the mode of files written/updated by Dropbox, but it wouldn't be the first time I'd be wrong.
I know I can just tell Git to ignore the file mode, but that's just masking the problem. I'd really like to understand it so I can make an informed decision of how to proceed.
Thanks.
UPDATE
So here's a pretty decent representative example of a repository getting out of sync even though it's entirely contained within Dropbox. As we speak, my personal laptop is reporting a clean working directory for one of my projects:
$ git status
# On branch develop
nothing to commit (working directory clean)
My work laptop, though, reports a number of untracked files. Let me say that again: untracked files.
$ git status
# On branch develop
# Untracked files:
# (use "git add <file>..." to include in what will be committed)
#
# html/cake/console/libs/templates/
# ...4 more files...
# html/cake/tests/test_app/plugins/test_plugin/views/themed/
nothing added to commit but untracked files present (use "git add" to track)
How can that be? My ~/.gitignore
file is also shared across both machines (not that any of these paths are excluded in an ignore file). Is there another component of Git--or maybe Dropbox--that could be in play here?
I've gotten this exact problem under the same circumstances.
To stop the files showing in git status
you can set git to ignore file mode changes:
git config core.filemode false
This change is local to the git repository and will be synced along with the files.
You may want to check where you are setting your umask; it may be that dropbox is starting with a different umask than what your shell has. However, I believe that git ignores the group/other permissions and is mostly concerned with the execute bit, which should not be affected by the umask. Some thoughts for debugging:
git checkout -f
on the files in question, do they get the correct permissions?chmod
a file on one system, does that change get propagated?If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With