Wednesday, March 30, 2011

An svn users' tale of the Git (bare) learning curve.

Herein lies my woeful tale of Git assumptions and the specters of SVN, rabidly haunting my brain meats with errant lies.

I am an SVN guy. I'll outright admit it not matter how much 1337-credit i lose in doing so (offended? I also hate NoSQL and most of the major frameworks). However, with all you hip kids moving to Git, I felt the need to sip on the purple koolaid juts enough to hold a conversation with you criminally insane miscreants. This is the story how I perhaps sipped a little to much (double entendre!!!).

For those of you who are like me, and looking for a helping hand, i'm going to paste the fuck-off error i kept getting, and how I fixed it (with proper git workflow!):

refusing to update checked out branch: refs/heads/dev

By default, updating the current branch in a non-bare repository is denied, because it will make the index and work tree inconsistent with what you pushed, and will require 'git reset --hard' to match the work tree to HEAD.

You can set 'receive.denyCurrentBranch' configuration variable to 'ignore' or 'warn' in the remote repository to allow pushing into its current branch; however, this is not recommended unless you arranged to update its work tree to match what you pushed in some other way.

To squelch this message and still keep the default behaviour, set 'receive.denyCurrentBranch' configuration variable to 'refuse'.

If you're getting this error, read on! I promise you I have the answer. And not the "oh, just convert it to a bare repo" like the rest of the internet says. They are wrong. Join me in joyous perseverance!

Now, I've used Git on and off for a few years now, mostly to keep track of work on a local machine, however I wanted to implement a Git server that could keep track of a repo/ master branch much like how I currently use SVN. And that, is the beginning of "How I wasted a day of my life, a story of misunderstanding and hardship". I'm talking Ann Frank hardship. And as a personal note to you Git guys out there, DOCUMENTATION! seriously. How in the hell does that error at the top of the page help anyone? How about a "why this is bad" note or link? You wasted a day of my life, and i want it back.

If you meandered like a retard down the same path as me, you probably did the following:
  1. make directory on server, and git init
  2. add some files, git commit -a
  3. make directory on client, and git clone
  4. edit files, git commit -a, git push
  5. Git sez: "ERROR. YOU SUX. RTFM CUZ UR SHIT IZNT BARE. FUCKIN N00B."
After braving the depths of the internetz, I came across a cult of people explaining that "all you needed to do" was convert to a bare repo, and all would be well. This sounded a tab fishy to me, as up until this point nobody had cared to explain what a bare repo was (as I later discovered, it is just the contents of the .git directory. no browsable file structure). After reading a few websites on Git workflow, and heeding some sage advice from a local development firm (SRT), I bravely decided to abandon my SVN knowledge, and start playing with branches. Here is what i found (and what fixed my problem).

Create a git repo on your "Host/Storage Server":

mkdir repo
cd repo
git init

At this point, you have an empty master branch, so lets add a blank file (or copy your own files in to the dir at this point), and commit it.

touch README
git add *
git commit -a -m "here is my first commit"

Now at this point, if we were to clone the master, edit README, and commit from another machine, you'd get the fuck-off error ourlined above. So instead of fighting Git, lets place nice. Following the git workflow, you shouldnt be doing development directly in to your master branch (as it awkwardly attempts to point out in the error message). Instead, the master branch should only be deployment-ready versions of your code (ie: SVN tags). So lets add a branch in which we'll be doing some of our development:

git branch dev

Ok, now head over to your "Client/Dev Server" and clone the repo. I use ssh as a transport because its simple and I like that, but if you want to get all difficult and fancy, you can use the git-daemon which implements the git:// option (which is just ssh on port 9140 or some shit, so I would suggest the simple, cool-guy way, which is ssh).

git clone ssh://username@ip.or.fqdn/path/to/repo
git branch dev
git checkout dev

At this point, you have a full working copy of the git repo on your machine in which you have created and started work in the dev branch (like we made on our server). You can now feel free to mess up the joint by committing or editing files. Then simply:

git commit -a
git push

Bam! you have yourself a hosted Git server! Now that you have your working setup, I would suggest you read over this handy workflow which will help you further understand / make user of Git.

No comments:

Post a Comment