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 git-config insteadOf trick.

Here’s the bottom of ~/.gitconfig:

[url "git://anonscm.debian.org"]
    insteadOf = "git://git.debian.org"
[url "ssh://git.debian.org"]
    pushInsteadOf = "git://git.debian.org"

And tada! debcheckout picks the appropriate service (anonscm for anonymous access), and one is still able to push (through ssh) without having to change the URL in each and every .git/config file (which would also lead to higher CPU usage when updating afterwards).

Posted @ 24/05/2011 Tags: git

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:

 [[meta date="2009-07-02"]]

(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.

Posted @ 02/07/2009 Tags: git

wokking-copy.png

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…

Oh. Now. http://git.debian.org/ has pkg-webkit/upstream.git and pkg-webkit/webkit.git (Debian packaging).

Considering the first one, the history from June 2007 until takes 120MB (du -sh .git). There are two branches: filtered (180MB, .git included), and svn (460MB, .git included).

Also, checking ccache is installed and ready to be used (e.g. by prepending $PATH by /usr/lib/ccache) is always a good idea. Using colormake might also be interesting (once installed, set $MAKE to colormake, done).

So: Can I has a wokking copy?

Sure:

# 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
Posted @ 11/10/2007 Tags: git

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 by calling svk push -l.

Setup

A (remote) origin branch, a local master one, regularly pulled and 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 by using git-log origin/master..master.

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

Finition

git-push origin master
git-branch -D merger

Some bits of work, but a nice occasion to handle some git commands.

Posted @ 28/08/2007 Tags: git

Now the git repositories put under ~/public_git are visible through gitweb, here are the URLs for my git repositories out there:

My debootstrap branch is quite useless, now that upstream told me to do things differently, but at least it contains a working debootstrap for GNU/kFreeBSD.

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.

Posted @ 13/08/2007 Tags: git

SVN with git. One package: git-svn; two tools: git-svnimport, git-svn.

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 go.

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

Using -r BASE:HEAD is quite interesting since only the needed revisions are fetched.

Important: Don't forget to use git-svn and not git.

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 branches, tags, trunk are all available as directories, but it is also possible to have them as remote branches, using the following options: -T trunk -b branches -t tags.

Posted @ 11/08/2007 Tags: git

To share easily ones git branches, it is possible to store $foo.git repositories in ~/public_git on alioth, the repositories being then available at git://alioth.debian.org/~$login/$foo.git.

Edited: missing ~ before the login name...

Posted @ 02/08/2007 Tags: git

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.

  • hierarchy:

  • l10n.git

  • 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.

  • ideas:

  • 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.

  • open questions:

  • how to handle the tagging of the released (BTS'd) files? Will tagging with $package/$version/$bug be too much?

  • how to handle the Mail-Followup-To header for the second kind of scripts? Sounds like not that possible, after all.

Posted @ 11/07/2007 Tags: git

Summary of my setup

  1. Install ikiwiki

  2. Choose a hierarchy for the blog entries. It is blog/$year/$month/$day/$title.mdwn right now, and tags are stored under tags/.

  3. Enable some plugins. Currently:

  4. sidebar: integrate a menu bar on each page;

  5. tag: ease the creation of tags and links;

  6. pagestats: needed to generate automatically the list of the tags;

  7. prettydate: specify a string format for the Posted/Last edited dates;

  8. shortcut: enable many interesting shortcuts like [[debbug NNNNNN]] or [[debpkg package]].

  9. Create some placeholders:

  10. index.mdwn;

  11. tags.mdwn;
  12. tags/*.mdwn (one for each tag),

  13. Write a configuration file: ikiwiki.setup, enabling these plugins, and containing some basic information like origin and target directories.

  14. To do:

  15. learn the syntax for real;

  16. automate the creation of index.mdwn placeholders under blog/$year, blog/$year/$month, and so on. Extend a module to do so?
  17. poke the author of the calendar plugin so as to get the code;
  18. report that shortcuts containing slashes aren't working;
  19. integrate it in git.
Posted @ 10/07/2007 Tags: git