tags:

views:

283

answers:

3

Here is my situation. I keep a set of files on both my laptop, and a server. I already have a sync setup between the two locations using rsync. Recently I decided that a certain part of these files should be under source control. I am using git for this.

So I have shared/ which I sync using rsync. Then I have shared/stuff/ which is under git control. I will be using git from both locations on the repository that is local. I only work with one copy at a time, and I always sync the files back and forth.

I am the only person dealing with these files, and these two locations are the only places these files exist. The only reason I have git is because just today I accidentally deleted some code, and couldn't get it back.

So my real question: does rsync do anything that will break git? Or vice-versa?

Edit: For those that are curious, the reason I am using rsync to sync instead of git, is because I already have a great system for keeping the shared/ folder synced, and would like to keep the git repository in it.

+2  A: 

As long as you are only editing the repository on one computer and syncing before editing on the other, it will be okay.

Jeffrey Aylesworth
But those are two big caveats - especially the sync before edit on other. If you use git to synchronize (pulls, pushes), then you'd not run any risk - that is how it is intended to be used. As it stands, the technique is simply copying the remote repository over the local (or the local over the remote), running the risk of losing recent changes.
Jonathan Leffler
+3  A: 

There is nothing wrong.

Remember that git objects: commits, trees and blobs are immutable, so a git object storage is like a log, you only write new objects to it without removing anything, even when you "rewrite history". Not before git gc do you stop the world and prune. Git makes it hard to lose data.


If your repository is very big, and you repack it, rsync has to transfer the whole object database again, since git packs everything into a new, big pack file. If you want to repack, you can either use git repack instead which will create new packs for new objects without touching the old. Or you can repack once good, and mark the big pack file for keeping:

If you have a pack file called .git/objects/pack-fe017c0e9ea12841cd29458df7bd4421c2b12458.pack, just create one named .keep beside it:

touch .git/objects/pack-fe017c0e9ea12841cd29458df7bd4421c2b12458.keep

Now, git gc won't rewrite that pack file, but it will take all other small packs and objects and collect them together. The difference to git repack is that you won't build up a collection of lots of small pack files.

kaizer.se
+2  A: 

I do this all the time, but with Unison instead of rsync. The difference is that if you accidentally change something on both machines, Unison will detect the problem. And Unison even has the rsync algorithm built into it!

Norman Ramsey
The one problem with Unison is that I can't rely on it being installed on any (*nix) machine I touch, like I can with rsync.
Mike Cooper