views:

71

answers:

1

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?

+1  A: 

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:

  • Can you reproduce this on-demand? How?
  • What operating systems are you synchronizing between?
  • If you git checkout -f on the files in question, do they get the correct permissions?
  • If you simply chmod a file on one system, does that change get propagated?
Emil
To your questions: no (I see this frequently, but not consistently), Both Macs, I'll try that, yes (at least in the short term). I'll keep drilling into it and follow up.
Rob Wilkerson
A Google search for dropbox and permissions on OS X returns http://hints.macworld.com/article.php?story=20081009204908181 but I don't think that's relevant to the situation you are describing.
Emil
It's taken a while for this to reproduce itself. I haven't spent a ton of time trying, but I still can't reproduce it predictably. What I have now is one system where a few files have 644 perms and `git status` shows them unmodified. Another system where the same files are 644 and `git status` shows the perms modified from 755.
Rob Wilkerson