Clay’s Blog

Well, since it took me all day to figure this out again, I figured I might as well write it down somewhere so that at least I’ll be able to remember it the next time I want to create a new repo with Git.

The one thing that irks me is that I always try to create a bare repo on the server and then clone it to my client.  For some reason git doesn’t want to work this way even though that’s what my intuition tells me.

Anyway, the way to do it is to first create your working copy.  I’m making a little website so I have some code in /www/my-working-copy.  After you have some code that you want in the repo, you need to initialize a git repository and add your code to it like so:

After that’s done, you want to go your git-daemon’s base path and clone this repo there with a bare copy:

You should get a message like “Initialized empty Git repository in /my-git-daemon-base-path/my-remote-repo/” after which you may need to run update-server-info and you’ll also want to add a ‘git-daemon-export-ok’ file to the repo so that the daemon knows that it is okay to export it:

At this point you also will most likely want to add a ‘tracked repository’ named ‘origin’ to your working copy so that git will know where you want to push and pull from:

That’s it!  To test it out simply try a commit:

You should receive a message “nothing to commit (working directory clean)”.

At this point you probably want to push your changes to the repo.  Although the repo is created, it won’t be very useful until there’s something in it:

Cheers!

I remember getting lost a few times back when I first started using Prototype. I was trying to implement some form validation, which is pretty easy with prototype, but ‘old habits’ were getting in my way. Coming from ‘plain old javascript’, I was accustomed to using ‘return false;’ to cancel a form submission, but when you’re trying to separate form from function(and thats really the whole point of events), you don’t necessarily want to put javascript into your html. e.g.:

First of all, it’s ugly. More importantly though, it mixes your javascript and your html, if you want to rename your validator function you now have to dip into the HTML code(which should probably live in a different file)… ew, divs. Since you’re using prototype you should be using prototype’s event management. Here’s a sample:

And, in order to stop the form from submitting you would use Prototype’s Event library again:

This stops the submission event from ‘bubbling up(or down)’ to the Document Object and being submitted. This is our ‘return false;’

Putting it all together we get something like this:

..and there was much rejoicing. Our HTML and and javascript are separate, our lives are easier. Our new code also makes it clear that form submissions are actually events and that our validation function is a handler for that event.
Cheers!

Apparenly Ryan Campbell wrote on the same subject back in 2006, he claimed that Event.stop() didn’t work in Safari but as far as I know that’s no longer true.
Prototype’s api entry for event.stop.