ok, this is now official, i got paid for working on the C rewrite of git-merge during the summer ;)

just for fun, i collected some other projects with Hungarian students: samba, e17, freebsd, genmapp, xorg, drupal.

i recently had problems with bzr -> git conversion using tailor and now Lele pulled my patches so here is a mini-howto about how i did the conversion.

i did all this in a ~/scm/tailor/bitlbee dir (to convert the bitlbee bzr repo), but of course you can do it somewhere else, too.

create the dir and place there the tailor config. mine is like:

$ cat bitlbee.conf [DEFAULT] verbose = True [bitlbee] target = git:target start-revision = INITIAL root-directory = /home/vmiklos/scm/tailor/bitlbee state-file = bitlbee.state source = bzr:source subdir = bitlbee.git [bzr:source] repository = /home/vmiklos/scm/tailor/bitlbee/bitlbee.bzr [git:target] repository = /home/vmiklos/scm/tailor/bitlbee/bitlbee.git

and here is the update script: $ cat update.sh #!/bin/sh -e cd dirname $0 cd bitlbee.bzr bzr pull cd .. tailor -c bitlbee.conf

to update the import daily i added the followings to my crontab:

40 4 * * * ~/scm/tailor/bitlbee/update.sh &>/dev/null

and we're ready, you'll have a daily updated git import.

one minor note: the bitlbee.git dir is a non-bare repo and it's also a bzr repo which is not a problem (you can clone it and gitweb handles it) but if you plan to switch to git later, you probably want to clone it once get rid of that junk :)

..continuing last year's article. so another year passed by and it's time to look back and see what we did during 2007. probably i miss a lot of stuff but here is my list:

1) ability to go back in the installer to a previous point if you missed something. do you remember the days when one had to reboot if he/she wanted to do so? :)

2) compiz improvements. this is now settled down in current and it's pretty sane. we cleaned up the old compiz and beryl, we have a single compiz-fusion, it has a nice step by step documentation and it works fine both for kde and gnome.

3) asciidoc. i think we highly improved our documentation since we switched from latex to asciidoc. a user manual of 98 pages in a nice pdf format is cute, isn't it? :)

4) newsletters. Alex started to issue newsletters and recently phayz helped out us, so it's alive again. i think it's something great.

5) yugo. 'factory' was our previous i686 build server, it was a very old machine with a cpu of 300mhz and so on. it was time to replace it and now yugo does the job.

6) fwlive. this was an old project but only test versions were available, based on old frugalware versions. now there is a live version of every released version of frugalware, thanks to janny, boobaa and ironiq. great!

7) gnetconfig. the first graphical config tool from priyank. i'm really bad at any graphical programming, so i'm glad to see finally we started to work on guis.

8) gfpm. something users always wanted and now it's here. a true graphical package manager, which is not just a wrapper but properly uses libpacman. awesome.

9) fun. this is our update manager which can sit on the system tray (or whatever i should call kicker not to be kde specific ;) ) and notifies you if there is something to update. i'm sure this is more comfortable compared to watching the -security mailing list for updates or doing a -Syu daily :)

10) syncpkgd2. if you remember, the old method was that there were only clients and they tried to figure out what to build, they built and uploaded the packages. this was very suboptimal: it allowed only one buildserver / arch and it was slow. okay, being slow is the smaller problem, but every buildserver was a single point of failure. nowadays we have two i686 buildservers (thanks to boobaa) and it's theoretically it's possible to have two x86_64 buildservers, too. so even if one i686 buildserver is down, i can be at the beach, sipping a mojito :)

okay, i learned something today :)

you have a client behind a firewall and you have a server somewhere. and you want to ssh from the server to the client. that's exactly why ssh has a magic -R option!

if you do an

$ ssh -R 19022:localhost:22 server

that will mean that you can ssh to client:22 on the server by sshing to localhost:19022 on the server. yes, and it works even if the client is behind a firewall, yay! :)

update:

you probably want to add this to your ~/.ssh/config on the server as well:

Host client
        NoHostAuthenticationForLocalhost yes
        HostName localhost
        Port 19022

so that you can easily just type

$ ssh client

on the server

git-svnimport will be removed in git-1.5.4 and i don't think it's tirival to use git-svn (which is great for bi-directional work) to properly convert an svn repo (with multiple branches) to a git one, so here is a recipe.

first, just use git-svn to create a git-svn repo. it's a git repo but it's a bit weird, it contains metadata which is necessary for bi-directional operations and you won't see the branches by default when you clone it. ah and it's not a bare repo.

in this example i'll convert ooo-build's svn repo (it has several branches and tags, so it's a good example).

mkdir -p ~/git/ooo-build cd ~/git/ooo-build git svn init -s svn+ssh://svn.gnome.org/svn/ooo-build git svn fetch

this will take a while. once it's completed, you need to convert this to a bare repo:

mkdir ../ooo-build.git cd ../ooo-build.git git --bare init git config remote.origin.url ~/git/ooo-build git config remote.origin.fetch +refs/remotes/tags/*:refs/tags/* git config --add remote.origin.fetch +refs/remotes/trunk:refs/heads/master git config --add remote.origin.fetch +refs/remotes/*:refs/heads/* git fetch

and you're done! :)

of course this is an incremental operation, so all you need is to run git svn fetch and git fetch from cron to keep the mirror up to date.

update:

it turns out you can even do this by having only one git repo. it has benefints: you don't have to duplicate the object database. and it has one problem: if you later switch fully to git, then you want to remove the git-svn metadata - doing so is the easiest if you just clone the repo.

so - in case you want this, you have to:

mkdir -p ~/git/ooo-build.git cd ~/git/ooo-build.git git --bare init git --bare svn init -s svn+ssh://svn.gnome.org/svn/ooo-build git --bare svn fetch

and then you can fetch from yourself:

git config remote.origin.url . git config remote.origin.fetch +refs/remotes/tags/*:refs/tags/* git config --add remote.origin.fetch +refs/remotes/*:refs/heads/* git fetch

note: git config --add remote.origin.fetch +refs/remotes/trunk:refs/heads/master it unnecessary as git svn fetch will update this for you (it is different from git fetch)

thanks for devurandom from #git for pointing out that this is possible using git --bare init before git svn init and using git --bare svn fetch :)

it was a while ago when we registered at ohloh.net, but i recently re-visited that page, and i found some nice PR texts there ;)

Over the past twelve months, 18 developers contributed new code to Frugalware Linux.

This is a relatively large team, putting this project among the top 10% of all project teams on Ohloh.

For this measurement, Ohloh considered only recent changes to the code. Over the entire history of the project, 36 developers have contributed.

well, i always considered our team as a nice and good but small team, it turns out that if you count projects, we're not that small! :)

it also creates nice charts about what programming languages do we use, etc, etc. so it's a different approach, compared to cia, but it's interesting.

recently i needed to convert a cvs repo to git, in fact i'm providing a git mirror, so i need incremental updates.

here is the command i needed:

$ git cvsimport -d :pserver:anonymous@tcpflow.cvs.sourceforge.net:/cvsroot/tcpflow -C tcpflow tcpflow

yes, this will do the initial conversion and the incremental one, too. :)

tcpflow is a nice small console application to debug your network data. the usage is simple. just something like

# tcpflow -i eth0

is enough. you're recommended to start it in an empty directory :)

don't be surprised, the incoming and the outgoing connection to a server's given port will be logged to 2 different files ;)

git filter-branch is a new command in git-1.5.3 and today i met a situation where it was really useful. here is the scenario:

i have a 'vmexam' (like soxexam, "vmiklos' examples") repo, random small code chunks, every commit touches only a given subdir. after some time some projects need an own repo and i do versioned releases. this was the case with pyrssi, too

so i wanted to have a new repo with only the pyrssi-related commits and without anything else. this is exactly the case git filter-branch's subdirectory filter is for:

git filter-branch --subdirectory-filter python/cgi/pyrssi HEAD

then in the old repo i just rm -rf'd the code and i had it in the root dir of the new repo. yay! :)