I presented my Introduction to Git talk at
KWLUG tonight.
I was pleased to hear that folks found it enlightening.

You can grab my OpenOffice slides, as well as the demo scripts I used
during the presentation, by using git:

git clone http://foursquare.net/intro_to/.git

If you missed tonight's talk, I'm also booked to give it at the next
Drupal User Group meeting on Thursday, July 15, 2010, at 7pm.
You can find more details here.
That meeting is at 58 Queen St. in Kitchener (across the street from the
old KWLUG meeting place).

Special thanks to Paul Nijjar for providing the laptop tonight and the setup.

That is a pretty comprehensive list. I'm probably in the same camp as you
claim to be, having broken every one.

The rules are pretty strong as well. I'm still mulling them over in my
mind, but there is one that sticks out as unwise, or poorly written.
It is #3, which says: "I will not write a program that fails to do
tomorrow what it was able to do yesterday."

Taken purely literally, this prevents all change, all experimentation, all
feature-level refactoring. I'm sure this is not what the rule was intended
to say. I'm assuming it is more of an encouragement for better testing,
so that a bugfix in one area doesn't break a feature in another.

Even taking this rule as a Testing Rule, I think it overreaches. There
are steps that programmers can take to prevent regressions, but to assume
that it is possible, or even common, to prevent them all is wishful
thinking.

I think a better rule would be something like: "I will not refuse
or hinder the fixing of a bug that I have caused."

In the C library, there is a very handy function called mktime()
which takes a struct tm pointer, pointing to time data in the local timezone,
and converts it to a unix time_t.

There is also a very handy set of functions that goes in the other direction.
The function gmtime() takes a time_t and converts it to a struct tm in
the UTC timezone. And localtime() does the reverse of mktime(), converting
a time_t to a struct tm in the local timezone.

The one function missing is the reverse of gmtime().

One way to do it, via standard library function calls, is to adjust the
TZ environment variable to "UTC" and then call mktime(), which will then
use it as the current timezone. But that gets messy. Not only
do you have to save the old TZ setting to restore it afterward, if your
program uses threads, messing about with the global TZ variable is
hardly safe.

Another way to do it is to use gmtime() as a reference point, and
loop while adjusting the original struct tm until mktime() + gmtime()
gives you the result you started with. This is brute force and
inelegant, but it manages to do the job without fiddling with the
global environment.

When parsing ISO timestamp strings, this problem is hit pretty quick.
An ISO timestamp can contain a time in either the local timezone
or UTC, depending on the trailing 'Z' flag. In my research, it does not
appear that more specific timezones can be specified in the timestamp format,
so at least we only have two states to worry about.

After much searching, I've ended up with something that I find suitable
enough to release. I tackled this problem back in 2007 for the OpenSync
project (you can see similar code in the opensync_time.c file), but
looking back on it now, the code is not clean enough for me to reuse
very easily. And even though there's a vtime2unix converter function,
it leaves the burden of timezones to the user.

I took a look at Boost's date_time library as well, and while huge and
comprehensive, and though it breaks the problem of time, dates, and durations
into nice manageable chunks, it seemed to reverse the status of the
C library: it made UTC conversions easy, and local timezone conversions
hard. And it reads timezone information out of CSV files... I don't want
to have to maintain my own timezone database when the OS does it for me.

So, if I don't want to write my own conversion routines, and if I don't
want to maintain my own timezone database, I'm stuck with the C library
method, and the first two solutions. Might as well make it easy
to use.

for those people who may not be aware: 2012 is the time which
all the prophecies in all the religions point as being a "key
pivotal moment" in human spiritual development. there are _no_
predictions beyond that point, because the decision of where we
go, and what we do next, is to be made *globally*, as an entire
planet and a species.

With respect, I believe you may have overlooked at least one religion. :-)

There is no starting date that I am aware of in the book of Revelations.
But there is a time period predicted, commonly thought to be 7 years,
in which things happen that have not happened yet. So even if those 7
years started right now, the predictions would take us beyond 2012.

"We're so plugged into the consumer entertainment industry
that we don't know what's going on in the world. We know all
about Johnny Depp and Angelina Jolie and U2 and The Family
Guy, but we don't know the laws that are being passed in our
countries. We don't know about the injustices of our social
systems. We don't know where our food comes from, or the
suffering required to get food onto our table. We don't know
about the people in our neighbourhoods who are writing books
and making movies and putting on plays and singing in choirs
and running garage bands. Just like the citizens of The
Matrix, we are mostly oblivious to reality, in part because
somebody has convinced us that consuming entertainment is a
worthwhile pursuit."

vicious
writes with annoyance about Gnome's git setup that
requires tags to have a GPG signature.

I think the reasoning should be viewed as less of a security
measure for the source tree itself, and more of a best
practice. Consider it a
kindness extended to your end users.

Developers who commit to a tree are often familiar with the
code. Those that are truly involved in a project may read
every commit that comes in. They know what the code is
supposed to do, and how it works. They know who the other
contributors are, and they are in the best position to spot
defects, bugs, or security holes.

The end user has none of this advantage. In most cases, he
doesn't even know where the source code is. He wouldn't
know how to read it if he did. And he may not know a good
patch from a bad one, nor have the time to figure it out.

How do you bridge this chasm? The most practical way is to
have a string of GPG signatures from the developer to the
end user, and make it easy for the end user to verify this.

So, the developer signs his release with his GPG key. The
distro packager checks this key, builds a package, and signs
that with his own GPG key. And the end user downloads the
updated software with the packaging tool, which
automatically verifies the package signature. A very
friendly verification chain from developer to end user.

So the question is: if you're not willing to sign a tagged
release of your software, should you be in charge of
releasing the code to end users at all?