开发者

Unsync'd Git Repository in Dropbox

开发者 https://www.devze.com 2023-01-17 05:20 出处:网络
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

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:

  • 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?


The fact you are using Macs is relevant - the Macworld Hints article mentioned in a comment explains the issue (but read down to the comment that explains how to fix permissions with chmod u+rwX etc, rather than absolute permissions that may mess things up).

This Dropbox Support answer explains what's probably going on and how to fix it - related to how MacOS X Leopard (10.5) changed the default usage of ACLs.

0

精彩评论

暂无评论...
验证码 换一张
取 消