Alternative view: by date.
The recent Alioth migration (thanks,
Alioth folks!) led to slight variations in the URL schemes for various
VCS. I guess some migration path will be considered but in the
meanwhile that seemed to be a good example for the nice
Here’s the bottom of
[url "git://anonscm.debian.org"] insteadOf = "git://git.debian.org" [url "ssh://git.debian.org"] pushInsteadOf = "git://git.debian.org"
debcheckout picks the appropriate service (
anonymous access), and one is still able to push (through
without having to change the URL in each and every
(which would also lead to higher CPU usage when updating afterwards).
Some time ago, the box on which my blog is hosted went dramatically down, and I had to restore the blog by populating the git repository again, from my local copy.
Unfortunately, that means that the wiki had to be rebuilt from scratch, and all creation dates were messed up, leading some planet-like sites to show all of my posts again.
To ensure that this won’t happen again (even if I switch branches in the git repositories, move some files around, trash the ikiwiki cache, etc.), it looks like using meta dates is the way to go, for example:
(One can use
2009-07-02 00:00:00 and
2009-07-02 01:00:00 to sort
several entries on the same day, too.)
This way, all pages are rendered identically on every system.
To help maintaining those extra dates (kind of a burden, to be
honest), I’ve written a tiny Perl script to automate
it, and specified an alias in
.git/config for that repository:
[alias] ikiwiki-check = "!blog/2009/07/02/ikiwiki-dates.pl"
Inline replacement (in case of conflicts: same date without time, or
with same time) or additions are then performed, and
git status will
show what needs tweaking.
More work that I initially imagined, but robustness should follow.
Getting back to a working copy of WebKit:
$ svn up svn: REPORT request failed on '/repository/webkit/!svn/vcc/default' svn: REPORT of '/repository/webkit/!svn/vcc/default':… …413 Request Entity Too Large (http://svn.webkit.org)
Combine svn and http transport… And the approximate size of a working copy is around 800MB…
Considering the first one, the history from June 2007 until takes
du -sh .git). There are two branches:
.git included), and
Also, checking ccache is installed and ready to be used
(e.g. by prepending
/usr/lib/ccache) is always a good
idea. Using colormake might also be interesting (once
So: Can I has a wokking copy?
# Fetch $ git-clone git://git.debian.org/git/pkg-webkit/upstream.git $ cd upstream # Check local branches $ git-branch * filtered # Check all branches $ git-branch -a * filtered origin/HEAD origin/filtered origin/svn # Work on the full sources, and make sure $ git-checkout -b svn origin/svn $ git-branch filtered * svn # Set the build environment, and build $ ./WebKitTools/Scripts/set-webkit-configuration --release $ ./WebKitTools/Scripts/build-webkit --gtk # In case the build is interrupted, “make” from there $ cd WebKitBuild/Release $ sudo make install
The goal is to lump some commits together because they should have
been just one. That's the kind of thing that can be done with
svk push -l.
origin branch, a local
master one, regularly
pushed. Some commits are in the
master branch, and they should
be pushed into
origin as a single commit. The log diff can be seen
Create a single, equivalent commit
git-checkout -b merger origin/master git-merge --squash master # HEAD isn't modified (squash commit), # fast-forward git-commit -m 'Commit message' git-log origin/master..merger # Shows the wanted diff
Apply that diff to master
git-checkout master git-reset --hard origin/master # Reset master to origin/master git-log origin/master..master # Shows nothing git-rebase merger master # Apply the (only) additional commit # from merger to master git-log origin/master..master # Shows the wanted diff
git-push origin master git-branch -D merger
Some bits of work, but a nice occasion to handle some
Now the git repositories put under
~/public_git are visible through
gitweb, here are the URLs for my git repositories out there:
debootstrap branch is quite useless, now that upstream told me to
do things differently, but at least it contains a working debootstrap
DebLog is a Perl module to access build logs. It is not yet
finished, but it can help fetch some logs and compare them. See the
scripts/ directories for examples.
SVN with git. One package: git-svn; two tools:
First thought: Oh, I don't need to modify things, let's use
git-svnimport. Bad guess. After some revisions fetched from
blender.org, the download gets stalled, and no way to resume. That's
documented in Debian bug #436930.
After having asked on
#git/irc.freenode.net, it looks like
git-svnimport is quite unmaintained and that
git-svn is the way to
git-svn clone https://svn.blender.org/svnroot/bf-blender
Far better, but after 6000+ revisions, interrupted download, and impossible to resume it. Damn (but thinking about it, I might have used the wrong command). Another way to do that:
git-svn init https://svn.blender.org/svnroot/bf-blender # Get 10 revisions git-svn fetch -r BASE:10 # Get the rest git-svn fetch -r BASE:HEAD
-r BASE:HEAD is quite interesting since only the needed
revisions are fetched.
Important: Don't forget to use
git-svn and not
Now, two branches:
master, local, and
git-svn, remote. Go!
$ du -sh .git/ 1.1G .git/ $ time git gc real 67m14.503s user 7m26.616s sys 0m57.740s $ du -sh .git/ 221M .git/
And all the project's history is there! The
trunk are all available as directories, but it is also possible to
have them as remote branches, using the following options:
-b branches -t tags.
To share easily ones git branches, it is possible to store
~/public_git on alioth, the repositories being
then available at
~ before the login name...
The idea is to have backups of working files easily, as well as easing some
tasks like sending bugreports with attached files, ensuring
msgcat has been
run, fetch the new
templates.pot file from the server, etc.
Various thoughts on using git to manage localization.
l10n.git/po: upstream PO files.
l10n.git/po-debconf: debian debconf screens.
l10n.git/scripts: scripts to ease the manipulation of translations, update of working files, etc.
adaptation of bubulle's script for this layout, maybe using ReadLine to ask for the package, version, and file to send;
same kind of scripts for sending RFR (or RFRn), LCFC (or LCFCn) from the commandline.
script to which a TAF or MAJ mail can be piped, so that the appropriate file is fetch from the server;
script to which a diff can be piped, so that it gets applied (if possible) and commit'd in the tree, automating the addition of the submitter's mail in the log;
script(s) to check for missing msgcat invocations, incomplete translations and so on.
how to handle the tagging of the released (BTS'd) files? Will tagging with
$package/$version/$bugbe too much?
how to handle the Mail-Followup-To header for the second kind of scripts? Sounds like not that possible, after all.
Summary of my setup
Choose a hierarchy for the blog entries. It is
blog/$year/$month/$day/$title.mdwnright now, and tags are stored under
Enable some plugins. Currently:
sidebar: integrate a menu bar on each page;
tag: ease the creation of tags and links;
pagestats: needed to generate automatically the list of the tags;
prettydate: specify a string format for the Posted/Last edited dates;
shortcut: enable many interesting shortcuts like
Create some placeholders:
tags/*.mdwn(one for each tag),
Write a configuration file:
ikiwiki.setup, enabling these plugins, and containing some basic information like origin and target directories.
learn the syntax for real;
- automate the creation of
blog/$year/$month, and so on. Extend a module to do so?
- poke the author of the calendar plugin so as to get the code;
- report that shortcuts containing slashes aren't working;
- integrate it in git.