Right now, I'm trying to get a handle on working with remote repositories. In theory, because git is fully distributed, you don't need a central repository. However, I want to use remote repositories to (1) ensure my data is backed up (I have access to a Solaris server with a RAID and regular disk backups), and (2) allow easy synchronization of my work between the various machines I use (office PC, laptop, etc.)
The main idea with git is that repositories and working directories should be inseparable; all work should be versioned. Being a distributed VCS, git gives you lots of ways to synchronize changes between repositories. All well and good.
However, weirdness ensues when you consider what git should do when you push (commit) changes from a local repository to a remote repository. If you push into a remote repository that has a working directory checked out from the branch that you are pushing into, git does weird things. I won't even attempt to describe what happens, since I don't understand it. Suffice it to say that it's not a useful behavior.
One solution, as helpfully pointed out by the git cvs migration help file, is to create the remote repository as a "bare" repository, meaning that it does not have an associated working directory. So, the series of steps is something like:
server$ cd /some/directory && git --bare initThe "origin" in git push origin evidently refers to the remote repository from which the local repository was cloned.
client$ git clone username@server:/some/directory
[ add some files ]
client$ git add files...
client$ git commit -m"Added some files..."
client$ git push origin
3 comments:
I've found that an understanding of git's internals is pretty helpful for me in figuring out some of the weird behavior that you mention. There is a reasonably good overview in this talk:
http://www.gitcasts.com/posts/railsconf-git-talk
For archival/synchronization purposes, if you don't care about setting up everything yourself, then it's probably easier to use an external hosting service (gitorious, github, unfuddle, etc).
I have been ssh-ing to the backup box and "git pull"ing my work over to it. This seems to work fine.
I've also been unable to figure out git-push in the last 10 minutes :)
I feel that useful tools for developers should not require developers to understand the internals of that too. I could not feel more strongly about this in regards to version control tools, as most developers do not have a good understanding of the basics of version control and branching. This is one of the places where I feel git is a failure. As a replacement for subversion, git makes some bad usability aspects worse as too much is revealed about what the version control tool is actually doing and does not allow a developer to focus on development.
Post a Comment