Sync Hacks: How to Use Git with BitTorrent Sync

Sync Hacks is a column dedicated to exploring new applications for Sync, as built by users like you. BitTorrent Sync is a free, unlimited, secure file-syncing app. (And now, it’s 2X faster.) If you’ve got an epic Sync idea, use-case or how-to, shoot us an email at sync[at]bittorrent.com.

[wide]
[/wide]

In this week’s Sync Hacks: Josef Betancourt shows us how to use Git with BitTorrent Sync. Josef turned to BitTorrent Sync because Sync gives you the benefits of having a remote Git server without using a remote server – maintaining multiple copies all on your own machines. Now, he wants to show you how to get started. Read on for the whole tutorial (adapted from his original post here).

From Josef:

In this post, you’ll find simple instructions for using Git with BitTorrent Sync on Windows. I took the easy way out and “forked&#8221 a very well written blog post by Sergei Shvetsov that did the same thing, only using Dropbox.

While cloud-based solutions provide a good way to backup or remote a Git repository for ‘single developer’ situations, the main advantages of BitTorrent Sync is that it’s free and no ‘server’ is required. Described briefly: BitTorrent Sync is a server-less folder syncing system. Instead of using a remote server storage system, it creates a fast private peer-to-peer file sync system using a P2P protocol. (Note: it is not necessarily a replacement for a server or your backup system, but it is a welcome addition as it covers some limitations of those services, such as file size limits, and issues with speed and privacy.)

Overview

What we’ll do:
1. Create a local repo
2. Create a “bare” repo that lives in the Synced folders
3. Add the bare repo as the origin of the local repo.

Once complete, the synced folder that contains the bare repo is available on another system as if it was created locally. During development, the synced folder does not constantly transfer data over the network to other synced locations because we primarily use the working repo and rarely use the ‘bare&#8217.

• The machine with the source sync must be on to allow syncing. This is not true with a server-based sync solution like Dropbox.
• Damage is also synced: If one of the synced repos gets damaged, that damage is reproduced in all correlated syncs
• Repository ignored files are synced
• There was a discussion on whether the .git folder should be synced. Not sure I follow the rational.
• I don’t know if there are any issues with BitTorrent Sync for long term work with a Git repo. People have complained of such issues with Dropbox. See this post about Mercurial use on DropBox. In the comments of that blog post, robhamilton “… found that it would break the repo. Mercurial locks files and creates temp journal files which get sync’d by the dropbox daemon. My advice is to stop DropBox, perform your push/commit, then restart DropBox. Pulls and clones are read only.” Is this an issue with Git?