Take the 2-minute tour ×
Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

This is a problem that hard to describe (and of course hard to search for answer), the closest that I found is Moving two existing already-synced directory trees to git annex

I have two copies of my document text files, one on a desktop Linux machine, one on a laptop. Previously, I run rsync periodically to keep these files in sync both ways. I'd now like to move management of this problem to git, but was wondering what the cleanest way to start would be.

I've put files on my desktop into a remote git server, following the instructions on the web. That was fine. Now the problem to me is on the laptop side. I.e., I already have a half synced files and folders on my laptop, and I don't think the commonly suggested git clone would be the proper answer to my situation, would it?

Say that the files and folders on my laptop are already out of sync with my desktop's, both ways. What would the proper steps to get my document text files back in sync using git with my already-setup remote git repo?

share|improve this question
    
I'd suggest using unison: it is specifically designed for two-way (or multi-host) synchronization. –  eldering Aug 13 '13 at 9:01
    
Thanks, the unison is actually what I've been using, but now prefer git. –  xpt Aug 13 '13 at 13:39

3 Answers 3

up vote 1 down vote accepted

See the answer as to why using git for syncing isn't a good idea.

Here is a test case that shows how to sync git with two already populated directories.

cd /tmp
mkdir foo
cd foo
git init
echo "hello" > README.md
git add .
git commit -m "initial commit"
git remote add origin git@github.com:<myUser>/test.git
git push -u origin master

At this point I have a local git repo which is synchronized with my git server. I will now create a new copy of the REDME.md file as if it had been rsyn-ed to another machine

cd /tmp
mkdir bar
cd bar
git init
echo "hello" > README.md
git add .
git commit -m "initial commit"
git remote add origin git@github.com:<myUser>/test.git
git push -u origin master

Because bar is behind master, I am unable to push.

To git@github.com:<myUser>/test.git
 ! [rejected]        master -> master (non-fast-forward)
error: failed to push some refs to 'git@github.com:<myUser>/test.git'
hint: Updates were rejected because the tip of your current branch is behind
hint: its remote counterpart. Merge the remote changes (e.g. 'git pull')
hint: before pushing again.
hint: See the 'Note about fast-forwards' in 'git push --help' for details.

I tried doing a git pull. Git merged the repo's but did not download the file, because it already exists locally.

git pull origin master From github.com:/test * branch
master -> FETCH_HEAD Merge made by the 'recursive' strategy.

You must also always remember to do a git pull before changing any files on each system, otherwise you will get conflicts that need to be resolved.

share|improve this answer
    
I was trying to avoid using git pull to pull in everything since I've already get most of them in sync. If the latest updated version is always on one side (i.e., not on both), do I still need this approach? If there are updates happened to the same file on both side, wouldn't I have to resolve the conflicts any way? –  xpt Aug 12 '13 at 4:04
    
@xpt Git only sync's files that have changed between local and origin. I just ran a test to prove this. I am going to modify my answer. –  spuder Aug 12 '13 at 4:21

You can git clone to your laptop, then copy the existing files in your laptop over the working copy. You'll then can composed a merged file by checking the diffs, possibly restoring the deleted lines that you want to keep.

share|improve this answer

It does seem like using git as a synchronization mediator would be the perfect solution. I would recommend you steer clear from using git as a synchronization tool for the following reasons.

Git was not ever intended to work in this way.

Git performs slowly with large files (2)

Git does not sync empty folders

Git does not track file system metadata

Git does not track other git projects (any folder with a .git folder inside it)

A quote from githubs website

Though it sounds like Git would make an amazing backup tool, Git really doesn't work out well for backups over the long term

https://help.github.com/articles/what-is-my-disk-quota

If you've ever worked with a repo that has thousands of commits, git gets very slow. Dropbox or rsync are going to be the better tool for the job.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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