Easy question right? Just bare with me here..

I usually use Git to work with files on my local machine. I like this method because I can later check the files out on the shared drive for other non-git users to use. It is great because I can delete files (clean up) in my local directory and that cleans up remotely. I can leave all the extra files in the remote directory alone. This behaviour is why I do not simply rsync...

The only issue I'm having is in dealing with open files. Git stops the pull or reset when I encounter I locked file I need to change. Is this really a show-stopper? I may need to get a files out very quick and find it counter-productive to hunt down an unrelated open file blocking the process.

Can you help improve this process?

BTW: It is good enough to only update a file if the timestamp has changed. But I only want to update files that changed so that the incremental backups are not adversely effected.

Apparently this is uncommon so I'm not promoting it. The benefits are good for me though. This gives me fast local access to local files independent of network failure and basically seamless publishing to the backup drive. I just need to check-in often and push to make sure changes are backed up. It plays nice with other non-git files and users on the shared drive. Rsync falls short only because of the 'clean-up.' I can't --delete clean up without removing other users files. It may sound minor to clean up manually, but it is really a deal killer as clean up is error prone and requires testing.

  • 3
    The title is misleading: you know how to sync, you just want an "improvement" that kind of defies the purpose of software such as git, IMO. – schaiba Feb 13 '13 at 19:15
  • ^ ditto ^ this is not what git is intended for. – goldilocks Feb 13 '13 at 19:16
  • 1) I hope the title is better now - thank you. 2) I will give git my sincere apology next time I see him(or her). – jcalfee314 Feb 14 '13 at 23:26

Not to say there isn't a solution to this (although I don't know what it is), but, vis. "surely this must be a common task" -- probably not, because you are using the tool for a purpose it was not intended for.

git is a version control system, not a filesystem sync daemon or something. People doing VCS stuff are not in a rush to update things on a server without making sure their update is ready (we hope), so they are unlikely to be be bothered that it fails because something has obviously been overlooked ("I encounter I locked file I need to change" -- so make the changes you need to make, then commit).

Put another way, most users of git would probably hope there isn't a solution to this -- it's a user friendly feature.

  • @jcalfee314 : I didn't downvote you, and I apologize if I seem mean or rude; I was just trying to explain why using git as a fast directory sync might be problematic. If you are looking for alternatives, you might want to rephrase your question more clearly, because it seems to be a question about git. My advice is that you actually explain (in detail!) what problems you have with rsync; it probably can do what you want, you just need someone to explain how. That's what asking questions is for ;) – goldilocks Feb 13 '13 at 21:41
  • At this point it sounds like Git will not do this. Thanks for everyones input in confirming this. When I come up with something better I'll update it here. – jcalfee314 Feb 15 '13 at 12:58
  • I removed that comment .. thank you for clarifying; it is great advice indeed. – jcalfee314 Feb 15 '13 at 13:00
  • I need to organize my repository better and use rsync for those shared files and Git for the source code files. My mistake was having them all together. thanks for the input, this really helped. – jcalfee314 Feb 15 '13 at 13:15

Easiest: headless dropbox.

Best: network file sharing (SMB or NFS)

Sledge hammer (and probably not ideal): Capistrano deployment style. The gist is that you have a directory structure a la:

   |                      |
   -----releases          |
           |              |

Essentially, every git deploy creates a new release directory, then a symlink is flipped to the 'current' directory. Your open files won't care (though changes to them will remain in releaseB at that point.) You delete anything older than releaseC, and your directory is a 'fresh' version at all times.

  • I'm running the operation as a shared driver user. It is a windows shared drive. If I understand correctly, SMB would not support links. – jcalfee314 Feb 15 '13 at 12:54

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.