views:

106

answers:

2

What I want to do: On my (ssh remotely accessible) university machine I work on a project which I have put under git source control (git init, then git commit -a after every change, all works fine). Now I want to want to work on that project on my private machine at home. Should be easy, since git is a distributed vcs, right?

I read the git tutorial, which suggests to do a git pull at university to get the changes done at home. That won't work, since my machine at home is not remotely accessible. So I thought that I'd do a git push at home. That works, but it's complicated (requires git reset at university afterwards, etc.), since non-bare repositories are not designed for pushing.

Question 1: Is there an easier way than adding a additional bare repository to my setup (which would mean that I had: (1) the "main" bare repository, (2) the university working copy, (3) the home working copy)?
<Rant>If I really need that setup, I could have stayed with SVN.</Rant>

Question 2: If that setup is really needed, how do I create that bare repository (git clone --bare, I guess) and make it the "main" repository, i.e., tell the working copies that git push is supposed to go there.

PS: I know that there's a post-receive hook floating around that allows you to push into non-bare repositories. I tried it, but it didn't work well since the git version on the university machine is quite old (1.5.5.6) and misses some commands used by the hook. Updating is not an option, and I'd prefer a solution without third-party scripts anyway.

+1  A: 
  1. This question sort of sums up my experience with trying to sync two working copies. Eventually I figured it was more natural and simple to have a bare repository. It's not a "main" repository in the SVN sense - you can have one at the uni and one at home, for example, and push-pull between those.

  2. Somebody will probably post the proper way to set the bare repository as your push target, but without looking at the docs, I would simply delete the working copy and clone it from the bare repository again.

itsadok
+5  A: 

You really shouldn't push to the checked out branch as it effectively pulls the rug from under the remote working copy. It's then difficult to work out if the working tree is modified because the branch head has moved or if there were also local changes which would be lost by a reset --hard.

The simplest thing to do is to push to a different branch. You can then merge this into the working copy's checkout out branch (or rebase the local branch onto it) when you have access to the remote machine and need to work on it.

From home:

git push origin HEAD:from-home

From 'work':

git merge from-home

You can set up your config to default to a particular push refspec.

e.g.

git config remote.origin.push +master:from-home

A bare repository is often more natural. You can either clone it from an existing repository or, what I usually do, initialize a new repository and push the master branch that I want to it from an existing repository.

Charles Bailey
also, if you have the "bare" repo on your university account, you can use git-clone's `--local` or `--reference` flags to eliminate resource consumption of the multiple clones.
David Schmitt
`--local` is automatic for local clones.
Charles Bailey