Here is the situation. There are two machines, laptop A and workstation B. B has a fixed IP, A has a dynamic IP, and I want to avoid the need of connecting from B to A (setting up an ssh tunnel for example; for the sake of the argument, assume that ssh from B to A is not possible).

There is a git repository, /home/user/foo.git, on both machines. Problem: working on A, merge the changes on A:/home/user/foo.git and B:/home/user/foo.git. In the end, both repositories should be identical.

The simplest solution I was able to come up with is as follows:

A:~$ cd foo.git
A:~/foo.git$ git commit -a
A:~/foo.git$ ssh B
B:~$ cd foo.git
B:~/foo.git$ git commit -a
B:~/foo.git$ logout
A:~/foo.git$ git pull ssh://B/home/user/foo.git
A:~/foo.git$ git push ssh://B/home/user/foo.git master

(before being able to do that, I had to change git config on B and add a post-receive hook as described in the answer to this stackoverflow question)

My questions:

1) is the above correct? 2) is there a simpler way of achieving the same purpose?

  • Are you making changes on both A and B? Where is your merge step? – Faheem Mitha May 31 '13 at 15:20
  • Maybe I don't understand something, but git pull is described as Fetch from and merge with another repository or a local branch. – January May 31 '13 at 15:22
  • I would be very happy if I was told why this question is off-topic to unix.stackexchange.com. I would never commit the same mistake again. – January May 31 '13 at 15:22
  • Ok, I don't really use git, so I guess the merge thing may be my error. If people are voting to close, it is presumably because they don't think the question is sufficiently Unix-specific. However, I think it is polite to leave a comment if voting to close. I didn't vote to close, btw. – Faheem Mitha May 31 '13 at 15:25
  • 2
    @January This question is squarely on-topic here. Possibly the close voters saw that the question involves git, and decided to migrate it to Stack Overflow which has more version control expertise. However, you are perfectly welcome to post questions on version control here (as long as you're doing it on unix), just be aware that you may have a better chance of getting a good answer on SO. Since this question isn't so much about git intricacies and more about setting up communication over SSH, it would be at best borderline on Stack Overflow, so I do not recommend migrating it to SO. – Gilles May 31 '13 at 17:48

Your post-receive hook has some pretty dire caveats IMO!

I have a similar setup, but server B has two copies of the repo. One is a bare repo and used as the default remote ("origin") for both. Then I don't have to supply arguments to "git push" and "git pull". That last is the only simplification I have over the commands you're mentioning. (And in my case B is a server; I have an ARM box I can just leave on).

If you "don't really use Git", it's not necessarily the best idea. Git was designed for power, and the UI is still not as consistent as other DVCS's. Simpler tools for this use might include

http://git-annex.branchable.com/assistant/ (new - I've not tried it)

http://www.cis.upenn.edu/~bcpierce/unison/ (old standby, works over ssh)

Dropbox (non-free and requires internet connection, but slick and will optimize transfers over the LAN as well)

Or there's Mercurial or even Darcs. I think either would avoid the issue that Git requires an extra bare repo or a worrying commit hook. Mercurial should be more user friendly than Git. Darcs has a different design to any other DVCS... so that might not be the best idea. Looking at the docs it seems Bazaar would be dubious for this case.

  • +1 for Unison. I use it today in a star-configuration to sync between three machines. – Alan Shutko May 31 '13 at 19:25
  • I'll try Unison. The last time I was using Dropbox it was messing up permissions. – January Jun 1 '13 at 6:19

If all that's keeping you is that you can't ssh from B to A, but you can ssh from A to B, then establish a reverse ssh tunnel.

  • Yes, I did mention that possibility, but I prefer not to use it. Moreover, while it would allow me to avoid using dangerous post-receive hooks, it would not simplify the procedure. – January Jun 1 '13 at 6:24

I think that git it's not good for you, I also think that rsync it's much better suited for your task, since you simply have to keep files in sync git is not ideal in my opinion because:

  • you don't apparently need any branching/versioning/distributed model
  • you need to deal with files, git doesn't deal with files directly, in a nutshell git sees every "object" on your filesystem ( files and dirs basically ) as a SHA1 hash, as a consequence there is no way to really recover a file or to simply do anything specific to a file, the only thing that git is able to tell is if the content of your branch is changed or not, that's it, and it doesn't even keeps a real track in the middle, for example the checksum is done when you commit not when you add files to the stage.
  • rsync is what I am using now, and it sucks :-) Firstly, I cannot easily compare the changes -- if changes were done in parallel on both systems (not to mention: merge the changes). To find out which version of which file is newer on which system I have to rsync back and forth, ssh or sshfs mount and vimdiff the files. – January May 31 '13 at 18:13
  • @January download a random git repo and try git log -p <filename>or git log <filename>, you will get a kind of a diff for each milestone in the history that is about that single file, if this is enough for you, than git is probably the right choice. a quick introduction for git youtube.com/watch?v=ZDR433b0HJY to get an idea about how it works – user2384250 May 31 '13 at 18:23
  • yes, I know, that is why I was considering git. – January Jun 1 '13 at 12:51

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.