lee/hpr-knowledge-base
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Initial commit: HPR Knowledge Base MCP Server

Browse Source 
- MCP server with stdio transport for local use
- Search episodes, transcripts, hosts, and series
- 4,511 episodes with metadata and transcripts
- Data loader with in-memory JSON storage

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude <noreply@anthropic.com>
This commit is contained in:
Lee Hanken
2025-10-26 10:54:13 +00:00
commit 7c8efd2228
4494 changed files with 1705541 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

422
hpr_transcripts/hpr2446.txt Normal file
View File

@@ -0,0 +1,422 @@
Episode: 2446
Title: HPR2446: Git server and git hooks
Source: https://hub.hackerpublicradio.org/ccdn.php?filename=/eps/hpr2446/hpr2446.mp3
Transcribed: 2025-10-19 03:13:44
---
This is HPR Episode 2446 entitled Git Server and Git Hooks.
It is hosted by Klaatu and in about 41 minutes long and carrying a clean flag.
The summary is Klaatu talks about running Git on a server and explains Git Hooks.
This episode of HPR is brought to you by archive.org.
Support universal access to all knowledge by heading over to archive.org forward slash donate.
Hi everybody this is Ken from HPR with an important from Wednesday the 20th of December 2017.
The media in the HPR feeds will be served via redirect from archive.org.
If you run into any problems can you email admin at hackerpublicradio.org.
We've done quite a lot of testing and I'd like to thank everybody who helped out on that on the mailing list.
So nothing should change and nothing should be impacted.
All the URLs are going to remain this in the feeds.
It's just that for new shows and they will be downloaded via a 302 redirect to archive.org
and they'll be downloaded directly from there.
So we don't expect your problem but if there is contact us we great.
The reason behind this is that Josh at AnanasThost.com who has been providing our servers has been
receiving an unacceptable amount of traffic over the last period of
and that's resulted in slowdowns on the website and lots of issues.
So hopefully this move will take some of the burden off the website.
In addition to that if you can throw a few shekels in the direction of Josh we'd appreciate it.
If you go to any page on the HPR website there's a information there on how you help him.
So once again as of Wednesday the 20th of December 2017
the media for the HPR feeds will be served via redirect from archive.org.
Thank you very much for your time.
Hi everyone this is Clat 2 you're listening to Hacker Public Radio.
I'm going to talk about Git servers.
You can run your own Git server. You can use someone else's Git server.
There are lots of ways to make Git available to yourself or to others on a very massive scale.
So I want to talk about three three different options that you have.
I'm going to skim over the one and then I'm going to go into great detail about the other two.
So the one that I'm going to skim over is the maybe the obvious one to a lot of people.
It's this quote unquote social coding sites and and I'm going to just use social coding so that I don't
have to to keep naming different services that are out there that you might look into.
But the social coding sites are those big cloud-based Git hosts that kind of popularized
Git I think or maybe they responded to the popularity of Git. I don't know chicken egg either way
they're very popular and a lot of people use them and to a lot of people these social coding
sites literally are Git like that's that's what Git is and any other approach to Git is kind
of a weird hack or something that only the only people people only do to be contrary.
So it's it's a huge deal and so and that's kind of part of the benefit.
The social coding sites are out there they're pretty well known some more than others.
So you get a lot of eyes on your code in theory. I don't know how I feel about the success rate
of this for myself for instance there have been projects that I put on on Git lab or GitHub when
I really want to get a lot of eyes on something and they just kind of get overlooked but I'm going
to temper that with a little anecdote which is yesterday I was on GitHub for work and I typed my
name into the search box because I thought I was looking for repositories within my name space.
And it turns out that I was searching for my name across all of GitHub which I didn't even know
that was possible but I ended up doing that and when the when my name came up it it it showed me
like where my name was in in people's repositories. It was quite interesting actually and I again
I actually did not know that there was this functionality. It just never occurred to me but you
can totally scrape all the files and everyone's repositories on GitHub or at least the public ones
by just searching in a search box that I don't really know how I got there though so I can't
tell you where to find that search box but it exists and I typed my name into it and every time
that my name appeared in someone's repository in code in someone's repository or text fields in
someone's repository it came up and so one of the things that came up was something called CBR2
CbZ and I thought wow that's interesting I have a project called CBR2 CbZ but it's not on GitHub so
that can't be mine and it must not be related to mine oh wait my name is in it so I went to look at
this repository and it turns out that someone had somehow found a little stupid little script that I
had written a long time ago like two two years ago just because I had a bunch of dot CBR files,
comic book files, CBR files and I wanted to make them into CbZ files because CbZ files are the
things that my particular devices actually can read whereas none of my devices take dot CBR files
the difference as it happens is that dot CBR files are zipped up or whatever archived with the
RAR RAR archive tool which I think is kind of a windows thing but there is an unrar for Linux
and then the zed extension means that it has been zipped up so I had written this little script
to automate the process of translating CBR2 CbZ and I'd put it on GitLab just because I mean it was
a stupid script but I figured well maybe I'll need it someday and so I threw it up there and kind
of forgot about it as you do and so someone had found this stupid little script and they brought
it over into their GitHub account and uploaded it and kindly retained credit because I didn't
I did not demand credit the license was the WTF public license so you can pretty much do whatever
you want to with it and they retained my name which was nice and they improved the script because
apparently there had been an error for some stupid reason I had used seven zipped I don't know P7
zipped I don't remember why I did that I'm sure I had some reason but if maybe I couldn't find out
the syntax for zipped I hate zipped but anyway so I used L7 or P7 zipped or whatever and I guess
there had been an error in some in some cases so they they swapped it out for generic zipped which
turns out probably is better anyway and yeah it was really cool and I just saw this and it hadn't
just been one person it was like two different people because there was my name there was someone
else's name and then there was the third person's name whose whose repository it was so the thing had
passed through I don't know at least two but possibly possibly a total of three including me
uh people's hands so at least one it possibly two people's hands and had just ended up you know
out there in the world and I never knew about it until I accidentally stumbled across it because
they kindly gave me credit so that was really cool and kind of I mean that was not a project that I
ever thought oh I need a lot of eyes on this I hope that I can build a community around and I don't
know if two people or one people counts as a community but it was still a neat thing to see so
anecdotally I'm saying if you put your code on a social coding site the chances are let's say
better than if you put your code on your own privately hosted Git server or if you don't put it
on a server at all for anyone to see at all so there are lots of coding sites out there I'm going
to recommend to to you one is Git Lab Git Lab seems to be pretty popular not as ubiquitous as
GitHub which if you're looking for a lot of eyes just indiscriminately I want a lot of people to see
this then probably GitHub is the way to go because that's kind of got I mean it's it's where all
the people are whether they like it or not if you're in technology today you're probably on GitHub
or I mean the site of technology that involves looking at code and stuff so that's that's GitHub
there's Git Lab the Git Lab advantage for me is that it's an open stack meaning that you can
download the community the community edition of Git Lab you can throw it on a big server somewhere
and run an organization off of it I have worked at a place that has done this and it does provide
the same kind of pretty web interface that people kind of have become used to because of the
social coding sites but the advantage is that it's all internal now I don't really see why you
would do that if your point if your if your goal is to get your code in front of a lot of eyes you
might as well just go online and put your stuff on the social coding sites so there's GitHub Git Lab
and then I'm going to recommend also not a bug.org so if you're not really concerned about putting your
code in front of a lot of eyes necessarily but you want a place that does all the configuration and
background work for you then not a bug.org is kind of a good place to go because it's a completely
open stack like everything's there's no community no community edition versus enterprise edition
anything like that it's it's just completely free it's it's pretty cool it's not a bug.org
and it's free and open Git repository hosting whether it's or not whether or not it's going to last
forever I don't know whether or not anything's going to last forever I don't know come to think of it
but I'm saying that very very specifically because my old host Gatorius.org I guess it must have
been uh win under at one point they they disappeared and they were hosting huge projects I'm talking
about cute and I think KDE and you know big big projects like that so it was huge and it was a
full free stack and that's kind of what drove me over to Git Lab eventually because they closed up shop
so the important thing here is to remember that you can push to multiple repositories when you're
using Git I did I've done an episode on that here on hacker public radio go listen to episode number
2130 I think it is it's all about pushing to more than one remote server uh when you're using Git
and that way you can make all your changes and push your changes to multiple places you're sort
of doing your own remote backups all in one go it's really quite handy so in other words you can
have a an account on all three of these places and backup you know and send your your code to all three
of them and it'll always be the same code base you don't have to worry about diverging or or
keeping track of anything or keeping things in sync they just stay in sync all right so those
are all the advantages sort of the disadvantages well one of the disadvantages like I say is that
well they might go away you never know getorious.org I would have never said that was going to go away it
was huge and well it wasn't huge huge it wasn't GitHub huge but it was huge it was probably as big
as Git Lab I guess it was a great little site and completely free and had lots of open source
projects on it but it it died it went away so you don't own the platform you don't possess the
platform so it's always at risk of going away like everything in this world is so that's a disadvantage
the other big disadvantage for me that actually makes a difference like this is the real sort of like
oh this actually matters to me it like to my daily sort of workflow is hooks access to Git hooks
Git hooks are powerful little back-end scripts that you can create so that when you push
something to a Git repository it triggers some action it can be a many number of actions in fact
that's the kind of the big deal about it it can really actually literally be anything I mean you
could program a GitHub to I don't know shut down your computer whenever you push to a Git
repository called power off I don't know you can do whatever you want get hooks are extremely
powerful the problem is and I mean that's they're so powerful that the social coding sites out
there generally don't give you really full access to the raw power of Git hooks Git Lab I know
just from experience has something called something they call web hooks which are very very similar
I never did figure out the setup process behind it but I didn't really spend that much time
because when I found out that I couldn't do what I needed to do on a web hook versus a GitHub I
just stopped trying and I went and did my own Git host and did my GitHub my GitHub there so
if you need really powerful workflow integration with Git a social coding site is probably not
going to provide you that I mean again you could probably download Git Lab and install it and
and kind of manage your own thing and do web hooks and figure that out but I mean at that point
you kind of have to wonder why you are bothering I mean that's not the my the advantages to
social coding sites in my view is just that you get a lot of eyes your mileage may vary okay next up
is Git on a server that is using Git on a server it's just raw Git it's normal old Git so the
advantages here are well everything that was the disadvantage to social coding you own the whole
thing you're in control of every aspect of it the disadvantage to running Git on a server and
saying hey everybody here's my server here's Git is that doing it that way is that Git users are
your that your Git users are also your Unix users so it's it's a one-to-one relationship if you've
got someone on the outside who wants to access the Git repository like for pushing and pulling and
well not pulling but for pushing access and that sort of thing developer access then they have
to exist on your Unix as a user on your server which you may or may not want now you can restrict
them in a variety of ways by only letting them get into a Git shell that sort of thing but it's
still something that possibly is a work for you to figure out and then you have this problem well
now that they're a Unix user and they've got this Git they've got access to Git how then now
they've got access to all Git so all the Git on my server unless I come up with some special
scheme like I off the top of my head I guess you could somehow sort of give them a specific port
number that they can SSH into and then use SSH to sort of to route them into a certain
repository and in that directory there's just one Git repository but I mean that that just sounds
like you're sort of inventing a a back end forget when other back ends already exist for forget
hosting rather so it's it's not necessarily something that I personally would think that you
would want to go super wide multi user with it just it doesn't seem like that would be the way
to go so in other words the disadvantage to just running pure Git on a server and using that as
your Git server is that there's no allowance for access management okay and then the final one
that we'll talk about probably not in this episode is Gitolight GITO LITE it's a software package
called Gitolight that you can get from Gitolight.com and it gives you all of that access management
in a very interesting framework that we will talk about when I talk about Gitolight the
advantage here is that it's got access management for your Git users so your Git users don't have
to they don't have to have a one-to-one relationship with who you know the users that actually
exist on your server the disadvantage I guess is again there's no pretty web front end so I mean
that could be a disadvantage or an advantage for me it's an advantage but some people because
of the social coding sites and that's how a lot of people are sort of getting into Git now although
I would argue that if that is your user base like if your user base expects some kind of GUI
interface into your Git server I do think that such a thing exists it's just not going to be a web
GUI it's going to be something like sparkle share or something really simple like KDE dolphin
with the Git integration module turned on or something like Git cola which is a great little
desktop client for Git so there are lots of options it's just it may not be a website and if your
users are okay with actually using an application not embedded in a web browser you should be fine
but what I'm going to go over in this particular episode and the next one I'll do something
different but then this one I'm going to talk about the Git server so a server running Git
is what it really is and in the next episode I'll go over Gitolight and how to configure it and how
it works because it really is an interesting system and and better than what I'm going to talk
about right now arguably but I want to talk about this now because it is important to kind of
understand how Git is supposed to be run and how you know what you know what what it actually has
natively versus what other services like Gitolight or anything else add to it so to run Git
on a server you need a server which I am doing a series on server admin so hopefully you will be
able to set up a server if you haven't already and then you can continue with this and you really
don't need anything too fancy I mean especially if it's just you and maybe a couple of other people
or certainly just you it can be it can be a Raspberry Pi in your in your bedroom it doesn't matter
it can just be whatever server you can get whatever you can make into a server now the first thing well
okay so before we do anything the first thing I should say is that SSH and Git are very tightly
bound together it again Git doesn't require SSH and Git has an allowance for using the Git protocol
it has a Git protocol that you can use but typically I think people use it over SSH because that's
a more secure way to do it and everyone's got SSH turned on anyway so it's kind of that's kind
of the de facto standard and so I'm going to go with assuming that yeah you're using SSH as
you're as you're Git portal as it were so first thing that you want to do is create so if you don't
know sorry so if you don't know SSH that well then you'd want to learn SSH really well and you'd
want to learn it well enough so that you can do fancy things like managing SSH keys and managing
passwordless login that sort of thing you want to have that really really you want to solid
understanding of that like where do you put your public key when you want to authenticate to a server
or rather when you want to set up a server so that you can authenticate without a password where
does that public key go do you know do you know the exact file do you do you know all the different
ways that can get into that file if you don't you want to review this stuff because it's so
important for Git access for both just running Git on a server as we are now or once you or if
you decide to run something like get a light okay so first thing you need to do is create a Git
user you don't have to but you should so you just do an add user get user or user add and then
dash in get user whatever however you want to create that user it's up to you then you switch over
to that user and you want to create your initial dot ssh framework with appropriate permissions and
this is important because this is how this is how you are going to access Git on this server so you
just do an s u space dash space get user and then you can make your directory dot ssh and you can
traumatic the dot ssh directory to 700 you kind of have to do that because ssh will fail if the
permissions are not strict enough and then you can do a touch dot ssh slash authorized underscore keys
and you can tomod that well you must tomod that to 600 authorized key file it holds all the public
keys of developers that you're going to let use your Git repositories so if that developer is
just you then you need to put your public key in that file if it's other people then they
need to send you their public key so that you can put their public key into that file so this is
all pretty standard kind of ssh setup stuff the difference I guess is that usually when you're
setting up an ssh authorized keys file is probably just a collection of your keys of your personal
keys and this is different because you're giving a bunch of people permission to log in to this
server as some entity called Git user so once a developer sends you a key all you're going to want to
do is cat developer bob dot pub into redirect redirect into slash home slash Git user slash dot ssh
slash authorized underscore keys and now that the public key is in the authorized keys the developer
named bob I think I said will presumably have the private key on his machine and so he can ssh
into the server as Git user so Git user at example dot com and then with a dash i probably would be
the identity file he can point to his private key and that will get him in as Git user on that
server now you don't really want to give all the developers access to your entire server even as
Git user there's just no reason that they should have unbound access to your server so
what you really want to do is give them access to something called Git-shell this is a restricted
shell that ships with Git like the whole Git package and it is intended for use cases exactly
like this so if you grip Git-shell in slash Etsy slash shells if it is not there you should
probably add it so you can find out where it does exist on your system with which
Git-shell and you can even just kind of redirect that the the output of of of that into slash
Etsy slash shells as long as you do a redirect redirect you don't want to just do it once
and then you want to do a user mod and make sure that your Git user user uses the Git-shell
not for instance bash or tcsh or whatever your system may default to and the the command for
that would be user mod space dash s for shell space Git-shell and then space and then the name of
the user which in this case is Git user so now Git user can only use ssh to push and pull
Git repositories and Git user cannot access a login shell they can access a Git shell but they're
not actually you know they can't ssh and then poke around on your server they don't get an
interactive shell they get they get responses to and from Git and that's it and that's a good
thing you want that now what we'll also do is create a group called Git user and you can do that
with either what is it group add or you may find depending on the system that you're running this
on that group that that Git user group has already existed but that's what you want to create
as a Git user group and so you'll probably want to then add yourself for instance or whoever's
going to be administering this Git get install to the Git user group and you can do that with user
mod as well so user mod dash a I think for append and then dash capital G for primary group maybe
or no additional group and then Git user and then space clatu or whatever so now you've got a Git
well you've got to get infrastructure with an ssh backend and so far there's nothing
that anyone can interact with because there are no repositories on the server so for that you kind
of I mean you don't have to do it this way but this is the this is the the intended method of
doing a Git of a sort of a centralized Git repository and it's really not a Git it is but it's
not a Git repository it's a bare repository and that means that it has no working tree that is
no branch is ever in a checkout state and that's important because remote users aren't going to be
permitted or will not be permitted to push to an active branch I mean how would you like it if
you were working in a dev branch and suddenly someone pushed changes into your workspace that
would not be very good so you you make a bare repository that can have no active branch ever
and you won't ever collide into into little issues like that I mean I say little issues they're
actually huge issues they can bring your work to a grinding halt now you can put this bare
repository wherever you want you can put it in well you you should put it in either slash opt
or slash user slash local slash share some place like that you don't want to put it in a user's
home directory because the permissions there are pretty strict so in some kind of play in a location
that's kind of meant to be a commonly shared location is probably a better idea I have found
so you would want to do Git init dash dash bare space slash opt slash through dot git
and then you want to chown recursively chown dash capital R get user colon get user so that's
the user and the group slash opt slash food dot git and then I take it a little bit further into
a charade dash capital R 770 for slash opt slash food dot git and you can manage all that yourself
and how you know whatever scheme makes sense to you like I say you could put it in a home directory
I just don't like mucking around too much there because I figure there's a certain amount of
privilege that I want people to have in order to get into a home directory and there's a
difference a set of permission that I want people to be able to get into a Git repository so
and of course I mean the path is going to eventually be the thing that your developers look at
so probably the shorter the better I guess it's up to you but I mean you could you don't even
have to nest it in anything you can just put it at the root level if you want slash food dot git
there it's there so here's where it'll show up so if I do on my client machine now so now I'm
the developer I'm Bob I guess so Git space clone space Git user at example dot com colon
and then the path to the repository so if you if you've done slash food dot git then that's
colon slash food dot git if you put it in opt then it's colon slash opt slash food dot git
and so on it could be whatever now you can also I mean like I say if you do put it in Git
users home directory then it would just be colon tilde slash food dot git and that's kind of
that's kind of easy to to type that's kind of nice but it just depends on on your tolerance
level for for mucking around permissions and changing defaults and things like that now if you
do if you did that right now you would be warned that you've cloned an empty repository and
that's fine it's just telling you that we you've that a bare repository has been created and it's
empty and that's okay that's that's a that's a normal thing to happen before you've put anything
into a into a repository and this is it this you're you're done this is this is your your setup
you're you're now running Git on your server and you can do whatever you want to do because you
own that server your developers can push and pull as long as they have access to that server
through the Git user user and they get access by sending you their public key and then you put
that public key in the git users authorize keys file and suddenly they can log in to a git shell
and do all the git things that they need to do keep in mind that this does not allow random people
to pull from this git repository because you have not configured the only gateway into this
git repository right now as it stands is through SSH so if you want to allow HTTP pulling or
git protocol pulling then you've got to allow that traffic on your server understood good okay
so the really cool thing about all this that I might as well get into are the the the the the
git hooks that you can implement now because you've got full control over your environment now
git has a couple of unique variables that it deals with and and it's kind of it's the the
documentation here is not super great it's a little bit sparse to be honest but you could
you could figure it out yourself by by doing test git hooks or you can look at the examples
that get ships within in the dot git slash hooks directory whenever you create a git repository
it's it's there in every single one so there's for instance a pre-push stamp dot sample
git hook which obviously is not live but but you can make it live by I think if memory serves
removing the sample the extension just pre-push and the the advantage of these sample files really
is it's kind of the the value of reverse engineering without really having to delve too deeply into
into documentation that as again as far as I can tell they they don't really exit the the docs
just don't exist for this yet it's it's not something that's super well defined outside of
the source code I imagine so the one of them the pre-push dot sample one for for example
lists in a comment some of the things that you can that you can expect from from git when when
pushing so the so the there's a variable automatically assigned it's dollar sign one
positional variable I guess and that's that's the name of the remote that you're pushing to so
when when git receives a a pushed item it it assigns to the dollar to the dollar sign one variable
the name of the remote that you're pushing to so if you're pushing to origin
then that's that's where that's dollar sign one it's the name the proper name of it
if you are if you are pushing to if you're not pushing to a name you're just pushing straight
just directly to some URI then that's the dollar sign two variable or rather that dollar sign
two is always the URI of where you're pushing to but if if there is no name to the place that you
are pushing to then dollar sign one and dollar sign two end up being the same the information there's
some more information about a commit when when you're committing you you get that after the dollar
sign one and dollar sign two you get the local reference the local shawsome the remote reference
and the remote shawsome something like that not all the samples are quite that clear in the dot git
slash hook folder but they're an interesting read and you kind of get an idea for what what you can
do based on that and you can always also just write a really basic hook script and just echo
dollar sign one dollar sign two dollar sign three that sort of thing so that you see exactly what
git is aware of when it's receiving pushes from you it's important to note that git hooks are not
themselves version controlled so git is not when you do a git push of of your data your git hook
directory is not being pushed with everything else git hooks is just sort of the standard set of
git hooks of samples and the location of of scripts that you write but it does not being committed
so if you write a super fancy git hook you want to very much make sure that that git hook is
version controlled by your or tracked or backed up or whatever by you manually so you may just
want to put it into a you know a utles folder or something like that in that git repository I don't
know how you want to do it but you do have to do that yourself git does not does not back up the
git hook scripts that you write as if that once they're in dot git hooks that doesn't get back
up okay so let's review how a git hook might work so the one that I use the only ones that I've
used have been post received that is they get triggered after a commit has been received there are
other types of hooks and like I say you can look at the samples to see what's possible but post
receive I feel is a pretty common one so that and that's certainly the one that I've used
which is probably why I think it's so common but yeah I mean I think it is common because
a lot of times what you'll want to do is you'll want to get a push and then you'll want to analyze
it and see okay well what if I what exactly have I received oh I've gotten something for the dev branch
well then I should email the the the person who needs to approve this commit and then they'll get
the email they'll go check it and then they'll they'll they'll review it and they'll merge it
to master or oh this is a push to master I should make sure that I I don't know actually what
you would do on master well like I say if it's a to master and it's you know you're doing web
development maybe you want to copy all that content to a web directory and and that way all of
your your changes go live and for the world to see that sort of thing so it's pretty common I think
to to look at the branch to which something has been pushed and then to trigger some action
based on that and there are a couple of different ways to find that information out like I've
like I've said we've got a couple of different variables here that get is aware of and we know for
instance that dollar sign one is going to hold the name of the of the place that the person pushed
to we know that dollar sign two is going to contain that you're the URL and everything after that
three four five six is going to be local reference local shawesome remote reference remote shawesome
so what you really want there is the ref name is what it's called that's the that's what would
tell you the branch to which this is being pushed so the way that you can find that well there are
two different ways the the way that I know how to do it is the bad way because I the only get hook
programming that I've ever done is it has been in TCSH and TCSH if you're familiar with it is a
horrible shell but that's what I know for this purpose so the the sort of I'll call it the canonical
incantation for finding the ref name in a get push is hash bang slash bin slash TCSH and then for
each arg so for each is all one word in TCSH space arg space parentheses dollar sign less than
close parentheses and then you want to set arg v to equal parentheses dollar sign arg close
parentheses and you want to set ref name equal dollar sign one and that's the end of your loop so
end that for loop basically reads in the first argument which is dollar sign one and then loops
it over over again and over writes that with the value of the second one which is dollar sign two
and then again with a third which is dollar sign three and so on and this is simply the way to
finally end up with the last argument which will happen to be the ref name and I happen to know
that because I've done it a lot now in bash you could do it actually a lot better you could just
use a bash array and then you could just tell it which which item in your array to look at but
TCSH doesn't have arrays so I just you just have to loop constantly until you until you run out of
arguments and it just so happens that I know that you will be left with the ref name
now once you have the ref name you've got basically the contents well you you have access I
should say to what the branch name is and you can you you have to do a little bit of parsing
but it's it's totally possible so set space branch space equals space back to get space rev dash
parse space dash dash symbolic space dash dash a brev dash ref space dollar sign ref name
close the back tick and now you've got your branch name so get rev parse dash dash symbolic dash
dash a brev ref dollar sign ref name provides you the the the the human readable string label of
the branch that has just been that that is receiving a push now with that information of course
you can do whatever you want from there you can say okay well let's set up an if loop and if branch
equals or I guess it could be what what are they called switches or cases or something but anyway
I again TCSH is what I've been using so or forget hooks so I would do like an if parentheses branch
equals equals master close parentheses then then do you know whatever you want to do with the
master branch if if it equals dev then do something else and so on to actually use your get hook
and when I say so on I do mean it can do anything I mean this is running on your server so you if
you want to play a song whenever something is pushed to master then you can do that you can trigger
you know ff play or or impact 123 or or aug 123 whatever you want you can just do whatever you
need to do with your script it is a it is a system level script that can that it has access to your
entire server so tramad plus x well so you put your little post receive script in dot get hooks
gets dot get slash hooks in your repository so the name of the script should be post dash receive
that's what you would want to call it so that get knows when to run it now all again all the
samples in dot get hooks are they're they're they're they're suffixed with dot sample so they don't
run but if you call it post dash receive and you tramad it with executable permissions then it will
run on upon post received when when get gets a push so tramad plus x slash food dot get or wherever
you put your repository slash dot get slash hooks slash post dash receive assuming this post receive
is the one that we just wrote together so now when any user commits to to our master branch
then the get hook is triggered the post receive hook is triggered and whatever you've assigned
you know whatever you've provided for that condition then happens so whether it's publishing stuff
to a website or playing a song or emailing a developer to say hey you need to approve this and merge
it at your at your leisure whatever that's how you do it so get hooks are really powerful they're
really cool they can do all kinds of cool things and it can it's it's it's more than just kind of
oh this is kind of cool it's it's really it's about integrating get into your workflow I've I've
used get to publish stuff to my web directory on a on a random server that I have out there
for for years now and it's just it's a beautiful process because I can just go into my get directory
switch over to my development branch do my little hacking on the little website stuff the HTML
and CSS and then I look at it make sure it looks sane merged into master and then push and when
it gets pushed and if so if I'm not done then I can push it to dev right I push it to dev and
nothing happens no get hook is is triggered well the post receive is triggered but it looks at
the branch and it says was it master no okay never mind I'm not doing anything so then if I if
I finally am ready then I can get merge master or get merge dev rather front from master and then
get push origin head and then the get hook again because it got her push it's triggered and it
looks at the mass at the branch the ref name gets the branch from the ref name and it says yep
this is a master this was a push to master so so we need to copy all these files over to far
www and suddenly it's live it's a beautiful beautiful thing it's really really neat and you
should do it and that's that's how to run a get server raw pure get server no nothing between
you and get it's just you get and a bunch of users not the most convenient thing next episode
I'm going to talk about get a light you've been listening to hecka public radio at hecka
public radio dot org we are a community podcast network that release the shows every weekday
Monday through Friday today's show like all our shows was contributed by an hbr listener like
yourself if you ever thought of recording a podcast then click on our contribute link to find
out how easy it really is hecka public radio was founded by the digital dog pound and the
infonominant computer club and it's part of the binary revolution at binrev.com if you have
comments on today's show please email the host directly leave a comment on the website or record
a follow up episode yourself unless otherwise status today's show is released on the creative
comments attribution share a light 3.0 license