I spent more time fighting
git and Github than I did in writing the code to support the
the code was straightforward and I had it done rather quickly.
Deploying the code was something else entirely.
So I finished the code,
and the new templates to generate the feed and my tests were good and life was fine.
I then committed my changes to
git and that's where the first problem occured—not all the changes were committed!
The issue came down to an overbroad directive to
git to ignore a certain file—it
was a general “ignore all files of the given name” instead of “ignore this one file” that I forgot about.
So I tagged the release (version
pushed the changes to Github
(for public consumption of the source code)
and then went to update the copy of
mod_blog on the server.
It was there when I discovered the critical missing file (one of the templates for the new JSON Feed).
I had been a bit too hasty in pushing the code out to Github,
so now I was stuck with releasing version
Only now something got munged up with my copy of the code on the server since it compiled the program with a version number of
instead of a version number of
A bit of background: I use
git to tag versions,
and in the
Makefile I have the following bit of code:
VERSION := $(shell git describe --tag) ... override CFLAGS +=-DPROG_VERSION='"$(VERSION)"'
so I don't have to update the version number in code by hand
override exists so I can specify different compiler flags and still have the version information propagated to the program;
I also handle the case when
git isn't available,
but that comes in later in my tale of woe).
git tag showed a tag of
git describe --tag was only coming up with
Did I not update things properly?
Was it a problem with the version of
git on the server?
Did I lose the signal?
Was it lost in translation?
Some quick changes,
That worked—kind of.
Now on the server the version was reporting back version
Then I discovered another issue.
I have code in the
Makefile to handle the case when the version number isn't available through
a check to see if
git describe --tag returned anything and if not,
use a hard coded version specified in the
to prevent me from pushing an update to Github with an incorrect version number in the
I have a script that is supposed to run when I push changes to Github
(specifically, when I push changes to a remote host).
Only the last change to that script rendered it non-executable,
so it wasn't running.
The version on Github had the wrong version number specified in the
and I was still having this weird “one version back” problem on the server.
I was still having problems with version
5.0.3 when I gave up.
I wanted a nice, clean,
I was on my way to version
5.0.137 the way things were going.
And all because I didn't check in a critical file because of a typo.
If only I hadn't pushed the code to Github so quickly.
If only there were a way to remove the tagged versions from Github,
but there didn't seem to be an obvious way to me.
As I eventually found out, there was a way—from the command line on my development machine, I just had to run this blindingly obvious sequence of commands:
GenericUnixPrompt> git tag -d 12345 GenericUnixPrompt> git push origin :refs/tags/12345
I'm surprised I didn't realize that sooner.
So I removed the tags for versions
made sure I had all the files and whatnot,
and re-released version
So now all is right with the world, and I have a new JSON Feed file.