Using shared git working area on multiple hosts

Question

I'm transitioning my personal projects from using subversion (svn) to GIT. In subversion, I've used a shared SVN working directory on several hosts (despite people telling me it wouldn't work), and it's proven to work nicely for me. It's important to point out this this is a single user solution, and I'm the only person making changes so I'm not running SVN commits on multiple boxes at the same time. In short, I'm willing to live with some limitations (if necessary) to simplify the overall management of my personal projects.

To understand why I'm looking to do this consider my configuration (below). I have a couple beefy machines each running several VMs. I have several large disks on "host1" and have file shares that other hosts (in the local LAN) access.

host1 (share \\host1\share)
  +vm1 (access SVN working dir \\host1\share\svnproj1, and svnproj2)
  +vm2 (access SVN working dir \\host1\share\svnproj1)
  +vm3 (access SVN working dir \\host1\share\svnproj1)

host2
  +vm4 (access SVN working dir \\host1\share\svnproj1)
  +vm5 (access SVN working dir \\host1\share\svnproj1)

laptop (access SVN working dir \\host1\share\svnproj1)
     But also have a svn checkout at c:\svnproj1

All of the OSs are Win7x64 or Win8.1x64. I'm currently using Tortoise SVN 1.8.2, and subversion 1.8.3 (on ALL of the hosts).

This approach lets me access the server's file share (\host1\share) from any host. In some cases, my svn repos are many years old and over 2 GIG having separate "SVN working areas" in each VM makes my VMs larger and complicates my VM Snapshots, and backups.

I also do not have to commit files until I'm taking my laptop for a business meeting. I work from home so this is not frequent. When I return from a business meeting or trip, I commit my changes on my laptop and update run svn update on any one of the 5 VMs and the files are updated for all 5 VMs. For me this is simple enough and has worked well.

So now I'm wondering if this same approach can work using GIT. Everything I've read says you can't (or shouldn't do this).

Here are the questions I have that will help me understand if this is even technically possible (NOTE: I'm already experimenting with this approach).

1. (Q) Does GIT store information on a host outside of the GIT repo (.git dir) and require that information in order to properly manage the git repo. If it does, then having several machines configured identically with that information is not feasible.

2. (Q) Does GIT create temporary files within the GIT working area? If it does, would that temp information screw up another copy of git running on another machine? If so, then again this approach is not feasible.

3. (Q) Does GIT have the same issue as Subersion in that all of the clients using a given repo need to be of the same version?

4. (Q) Does this approach fail if another OS is introduced (Linux, Apple OSX)?

5. (Q) If used a cloud storage provider like Dropbox, or SpiderOak does this solution still work?

6. (Q) Are there other questions or issues that I might run into when using GIT that I would not see when using SVN.

Again, it is important to note is that this solution only needs to work for me, there will never be multiple people making changes to the GIT repository, and I can live with some limitations if it simplifies the overall management of the VMs.

This article http://www.sitepoint.com/how-to-use-dropbox-with-svn-or-git-for-cloud-source-control-management/ did a nice job of explaining how to use GIT in the traditional way. For me the Dropbox solution is equivalent to the local LAN file share.

Answer 1

It should work no problem. Just put your git repo where your current svn working directory is on host1. I have done something similar where I share a git repo between a couple of computers using Dropbox (which is actually less advisable than what you're talking about because Dropbox will create a separate version of the repo if it cannot sync).

Here are answers to the questions you asked.

1. There is some information stored in a .gitconfig folder in your home directory, but all this is superseded by any config information in the .git folder, which is completely portable. It should not cause any problems. One thing - be careful to choose the same option for line endings on all systems, or configure it in the .git folder.
2. No (at least, not that I'm aware of). All revisions are stored in the .git folder, and the working copy is just regular files.
3. It would be best if they are all running the same version of git so you don't get weird bugs, but it might not cause problems if they were different versions and you only did basic tasks.
4. OS will not make a difference since the .git folder would be the same. Just choose the appropriate option for line-endings and pick the same option on all systems.
5. Yes, I have done it on Dropbox. The only problem is if Dropbox fails to sync and creates a conflicted copy of your repository. Then you have a headache to figure out which one has your most recent commits. This does not work for multiple users accessing at the same time because each user needs their own working copy.
6. No biggies. I made the switch on my personal projects a while ago and it was pretty smooth. There are tools that will help you import your svn history to git if you want.

Answer 2

The idea of git it that there is no central repository, each repository (even the one on your desktop machine!) has equal status. You can designate one as "master", but that's convention/workflow.

You can fetch/push changes freely among repositories. You can manage heaps of branches (yes, they work, and are extremely lightweight), merge, cherry-pick changes, graft a branch on the top of another (git will see to it that changes are correctly merged -- hopefully, it understands of "lines changed" not "concepts rethought"). You can have private branches (i.e., cooking up some harebrained scheme; if it works, promote it to official and publish -- push to others, to master --; if not, nobody's the wiser).