If screenshots were taken with a french version, instructions given here are for the english one. This will give you enough clues to perform the export whatever the localisation is. The Lotus Notes version I used was the 7.0.2 release.

So first, let’s start Notes and open your mailbox. You should be on a screen similar to this one:

Then, go to the File › Database › New Copy menu:

And you’ll get an export screen that’ll let you choose where to create a local copy of your database:

This will generate a .nsf file containing all your current mail.

Now that you have a backup, you are free to delete all your mails in Lotus Notes. By following this procedure regulary, you can create yearly or monthly archives of you mails without reaching the mailbox quota ! For example, this is how my local archive folder looks like:

This is a simple hack which get commit metadata out of a Subversion repository and generate an iCalendar file containing all commits of a given author. I used it back then to visualize in a calendar my commit activity. Nowadays this script is quite useless as services like Ohloh and GitHub provides great timeline and activity streams. But this script can still be usefull for private repositories.

And in the same spirit of this script, I uncovered maildir2ical.py, a script that look in a maildir folder for mails sent by a particular author, then generate an iCal file based on mail dates.

Then came Git. I knew that Git was powerful enough to let me manipulate the history (at my own risks). So I studied it during the last weeks until I found an acceptable way to do exactly what I had in mind. Here are my notes regarding this journey.

First, I need to get a local copy of my GitHub repository. That’s the place where I want all my code to reside at the end of the process.

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

In gitg, my untouched repository looks like this:

Notice all the pre-existing code.

Let’s create a history-injection branch from the init tag. The later is the root of my repository, as explained in my previous post on how I initialize my Git repositories.

git branch history-injection init

Then switch to our brand new branch:

git checkout history-injection

We are now in a safe and contained environment in which we can do all our dirty stuff. Let’s move the file we want to add in our repository:

cp ~/scripts/website-backup-2006_04_30.py ~/kev-code/website-backup.py

Commit this new file locally, as usual, but with a commit date set in the past:

cd ~/kev-code
git add --all
git commit --all --date="2006-04-30 23:17" -m "First version of a script to backup several remote websites via FTP and make bzip2 archives."

I can repeat the last steps to reconstruct the commit history of my website-backup.py script:

cp ~/scripts/website-backup-2006_10_29.py ~/kev-code/website-backup.py
git commit --all --date="2006-10-29 23:13" -m "Delete previous backups if nothing has changed."
cp ~/scripts/website-backup-2006_11_01.py ~/kev-code/website-backup.py
git commit --all --date="2006-11-01 23:14" -m "Keep monthly bzip2 snapshots of backups and incremental backups of the last 32 days thanks to rdiff-backup."
(...)

At last, the history-injection branch contain all version of website-backup.py:

Now I’ll use the rebase directive to insert the history-injection branch back in the main line (aka master). This insertion will take place just after the init tag. This translates to the following Git command:

git rebase --preserve-merges --onto history-injection init master

The --preserve-merges option is really important here to not let Git takes too much initiatives. Without this option, all our banches between the init tag and the head of the master branch will be rebased. Believe me, that’s not what we want.

I no longer need my temporary history-injection branch. Let’s remove it:

git branch -D history-injection

Now you should have a unique and straight history line from init tag to master head. Like this:

Commits appears to be ordered as they should but you may not be as lucky as me. In fact the recently merge commits are stuck at the “bottom” (just after the init tag, as we asked Git to do on rebase). And you may find you in a situation where commits of the whole master branch are not chronologically ordered.

Here is such an example. It happened when I tried to rebase the full history of my system-backup.py script:

I haven’t found a way to tell Git how to rebase by following commit dates. I know that something can be done with a command like:

git rebase --interactive init

But I haven’t succeeded yet. So I left these commits unsorted for now. I may write another blog post in the future if I find a way to cleanly sort them. In the mean time, If you have a solution, I’ll be happy to ear that !

Finally, when we have something that looks good, we can push our changes to our remote GitHub repository:

git push origin

But Git will complain: changing already-pushed commits is bad. As I explained several weeks ago, it’s dangerous but I don’t care. I’m the only user of this repository. So let’s bypass Git’s wise warnings:

git push origin +master:master

Et voilà ! By repeating these steps several times, I moved my code to GitHub, with a consistent and clean commit history.

This was shot in 1080p at 25 fps (to reduce light flickering) without any stabilization device. I may have use my LCD ViewFinder but I have no clear memory of this. Shutter speed was 1/50 and ISO set to auto.

I’m shooting video with my 7D for 7 months now and I think that’s the first time one of my shot is made public. That’s quite depressing as I still have tons of raw video to edit for several projects, but can’t go ahead because of a bad MacBook Pro…

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'
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 !

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):

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 usefull 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

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:

• For blog posts: http://kevin.deldycke.com/feed
• For blog comments: http://kevin.deldycke.com/comments/feed

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

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 !

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: