How I initialize my Git repositories

The first few days I used Git, I messed up my repository. I had to reset and recreate it from scratch several times. With enough trials and errors, I came up with an idea of how I should initialize my repositories. Let me explain in this post why git init is not enough to me.

To create a Git repository, nothing else is absolutely necessary than these few trivial commands:

$ mkdir kev-code
$ cd kev-code/
$ git init

But after reading some documentation and user experiences on the web, it looks like Git has some limitations when dealing with the root of a repository history. As I plan to heavily manipulate the commit history (to do some kind of code archaeology and history reconstruction), I need to have the widest time latitude to play with commits.

In this situation, I came to the conclusion that it’s a good idea to create an empty commit at the start of your repository life, and date it to the start of epoch. In the future, I’ll be able to leverage this intial commit as an ordinary history point from which I can start a branch. Then in this branch I’ll be free to mess up the history, until merging my changes back in the mainline tree.

So, let’s create an empty commit:

$ git commit --allow-empty -m 'Initial commit'

Then get the commit hash:

$ git log
commit 395290bcdb8ffccfbff89e42cb976077fbd3c1b7
Author: Kevin Deldycke <kevin@deldycke.com>
Date:   Tue Dec 1 15:37:49 2009 +0100

    Initial commit

We now change the commit date of our first commit to epoch start:

$ git filter-branch --env-filter '
>     if [ $GIT_COMMIT = 395290bcdb8ffccfbff89e42cb976077fbd3c1b7 ]
>     then
>         export GIT_AUTHOR_DATE="Thu, 01 Jan 1970 00:00:00 +0000"
>         export GIT_COMMITTER_DATE="Thu, 01 Jan 1970 00:00:00 +0000"
>     fi' -- --all
Rewrite 395290bcdb8ffccfbff89e42cb976077fbd3c1b7 (1/1)
Ref 'refs/heads/master' was rewritten

And check that the previous operation did what we expected:

$ git log
commit 8fe2934d1552c97246836987f0ea08e10ba749ae
Author: Kevin Deldycke <kevin@deldycke.com>
Date:   Thu Jan 1 00:00:00 1970 +0000

    Initial commit

Looks good !

For convenience, we’ll now attach a tag to this initial commit. Let’s call it init:

$ git tag "init"

This will came handy later when we’ll need to create a branch from here.

It’s time to push all changes to our brand new public repository:

$ git remote add origin git@github.com:kdeldycke/kev-code.git
$ git status
# On branch master
nothing to commit (working directory clean)
$ git push origin master --force

Counting objects: 2, done.
Writing objects: 100% (2/2), 159 bytes, done.
Total 2 (delta 0), reused 0 (delta 0)
To git@github.com:kdeldycke/kev-code.git
 + 86bd2c7...8fe2934 master -> master (forced update)

And here is the result on GitHub:

Maybe this “first commit” trick is unnecessary. So, if you have a better understanding of the issue, or can explain me why this is stupid, please tell me ! :)

Canon EOS 7D Movie Samples

Here is a collection of Eiffel Tower’s videos I took today with my Canon EOS 7D. These quick and dirty clips were shots this late afternoon.

Please don’t look at the image quality. That’s not the point. We’re interested in bitstream, video/audio codecs and media container here.

These files are as they came out of the camera and can serve as references. The idea is to provide raw data access to developpers and hackers to let them add or enhance 7D’s support to their software.

Here are seven 10 seconds video clips, corresponding to the 7 video modes offered by the 7D (that’s a lot of 7′s):

ResolutionFramerateShutter Speed
1920×1080 (1080p)23.976 fps (24 fps)1/50
1920×1080 (1080p)25 fps1/50
1920×1080 (1080p)29.97 fps (30 fps)1/60
1280×720 (720p)50 fps1/100
1280×720 (720p)59.94 fps (60 fps)1/125
640×480 (480p)50 fps1/100
640×480 (480p)59.94 fps (60 fps)1/125

Again, these files were extracted right out of the camera, without any modification.

Even if these details have no importance, here are some parameters under which these clips were shots (may be useful for debugging):

  • Lens: Canon EF-S 15-85 mm f/3,5-5,6 IS USM
  • IS: On
  • ISO: 100
  • Exposition compensation: 0
  • White balance: Daylight
  • Picture style: Standard
  • Auto Lighting Optimizer: Disabled
  • Highlight Tone Priority: Disabled
  • Peripheral illumintion correction: Off
  • Audio format: PCM, 48kHz, 16 bits
  • Camera firmware: 1.2.1

Feeds updated !

Last night I’ve changed the way my feeds are handled on this blog. I’ve taken care of all redirections with a mix of WordPress plugins, Apache’s 301 redirects and Feedburner’s “My Brand” service. So everything should be transparent from your (and your feed reader) point of you.

But since this blog moved from one location to another in the last past years, I doubt everyone use the right URLs. This update is a good opportunity to check that you are using the “official” feed URLs:

In the future, I plan to support these URLs only. So please update your feed aggregation settings ! :)

Lotus Notes’ Rich Text to MIME conversion error

Today I encountered a strange error while using Lotus Notes. I had a “Cannot convert Notes Rich Text message to MIME message” error:

This was triggered when I tried to move certain mails from one account to another. And to add insult to injury, this nasty and dangerous error will make you loose data.

Let’s say you want to cut and paste a batch of 10 mails. Then that error occurs while Notes paste the 3rd message. It means you’ll loose the last 7 messages of your batch. Why ? The 10 messages will be removed from their original location on cutting, and the last 7 messages will be trapped in the copy buffer. Isn’t that a reasonable reason to hate Lotus Notes ?

Anyway. After several tests and experiments, I finally found the common property shared by all those reluctant messages. They all have inline images embedded in the body of the mail, like the one below:

In mail edit mode, you can get properties of these objects and get confirmation that they are inline images:

As you can see above, the edit mode lets you manipulate (cut, copy, paste, …) these embedded pictures. Let’s take advantage of this to fix our initial issue.

Here is my procedure to make these mails pass through the conversion error:

  1. In Notes’ edit mode, cut all inline pictures, one picture at a time;
  2. For each cutted picture, paste it as a new image in the image editor of your choice (Gimp did the trick for me);
  3. Save each image on your local disk;
  4. Now that all inline images are removed from the original mail, attach (but don’t paste) to it all the images you saved in the previous step;
  5. Finally, save mail modifications in Notes and you’ll be able to move the mail without the conversion error.

This is really dirty, and isn’t bearable past a few mails. But that’s the only solution I found so far. Of course if you have a superior/automated way to address this lame bug, I’ll be happy to hear that ! :)

How-to fix bad commit authorship in Git

Several months ago I commited some code in my GitHub repository, but I did it from a temporary system. If I registered my authentication keys correctly to commit stuff, I forgot to create a minimal ~/.gitconfig file with the right stuff in it.

The result was not good looking, as my usual name and mail address were not attached to the commit:

Let’s fix this !

First, get a local copy of the remote Git repository:

git clone git@github.com:kdeldycke/kev-code.git

What was missing in my ~/.gitconfig file were the following options:

[user]
name = Kevin Deldycke
email = kevin@deldycke.com

These values can be set with Git command line with the following syntax:

--author 'user.name <user.email>'

The commit I want to change is the latest in history, so I’ll use the --amend directive to make my changes. Putting all things together, our final command becomes:

git commit --amend --author 'Kevin Deldycke <kevin@deldycke.com>'

After this, here is how the local branches looks like in gitg:

Using the git log -n1 command, we can compare the old commit:

commit 81a26f03901918ed4a954d964b2659187f1cc988
Author: kevin <kevin@laptop-kev.(none)>
Date:   Mon Mar 8 22:49:43 2010 +0100

    Update old shop logo with the brand new one

with the new one:

commit adf4620f3d8a89746dd643dcefc3f900f0f69878
Author: Kevin Deldycke <kevin@deldycke.com>
Date:   Mon Mar 8 22:49:43 2010 +0100

    Update old shop logo with the brand new one

Notice the fixed authorship. The commit ID was also updated as it’s just a hash depending on commit metadata.

Now we can push our changes back to the remote repository:

git push origin

But this doesn’t work and throw the following error:

To git@github.com:kdeldycke/kev-code.git
 ! [rejected]        master -> master (non-fast forward)
error: failed to push some refs to 'git@github.com:kdeldycke/kev-code.git'

This is Git protection mechanism in action. Modifying already-published commits like this is a bad idea. It can break updates of other developers’ repository (if they already have pulled the commit we’re trying to change).

In our case we will force the remote repository to take our changes:

git push origin +master:master

As I told you before this is bad, but nobody really cares: I’m the only person working on this repository ! ;)

Finally, you can contemplate the result on GitHub, a clean and tidy commit history: