… or something like that… I planned to write a
short note about how to start with using git-svn so I can provide a pointer to some of my colleagues. It turned out that git has too many nice features that you should be aware of.
Hopefully my notes (now being a reference for myself as well, thx to
gebi for all the help and feedback) are useful anyway. If you think something (more or less essential, or at least something most of us should be aware of) is missing: please feel free to mention that in the comment section of my blog entry, thanks.
Disclaimer: I’m still happy with
mercurial for what I - and we at
grml in general - use it: linear, but anyway distributed development. git on the other hand provides some really nice features. Rebasing and branching with git is really great - so non-linear development just works. As usual: use the right tool for the right job.
git is a
bit complicate to use. Not only but
especially in the beginning. On the other hand I’m not such a big friend of subversion. If you
wanthave to use subversion (
Graz University of Technology for example provides
a svn service to their students and employees) but prefer to work with git instead you should be aware of
git-svn. git-svn gives you bidirectional operation between subversion and git.
First of all make sure you have all you might need when working with git. Make sure to use a current version of git (I’m refering to version >=1.5.3). Just execute the following command line on your Debian system to install all relevant packages:
aptitude install \
git-buildpackage git-core git-cvs git-daemon-run \
git-doc git-email git-gui git-load-dirs git-svn \
gitk gitweb qgit
Now let’s start with some general and basic configuration:
# Remove directories from the SVN tree if there
# are no files left behind, configure it globaly:
git config --global svn.rmdir=true
# Want some more global, personal git configuration?
for line in
user.name=Michael Prokop
user.email=foo@example.invalid
color.diff=auto
color.diff.new=cyan
color.diff.old=magenta
color.diff.frag=yellow
color.diff.meta=green
color.diff.commit=normal
do
git config --global $line
done
Check out
man git-config for much more details about configuration options.
First tip: set ‘g’ as an alias for git so you don’t have to type that much. I’ll write the long version in the following examples so copy/paste works for everyone. Make sure to use the short options of git itself as well: use ‘git co’ for example instead of ‘git checkout’. You can define your own aliases inside git as well - either manually in ~/.gitconfig or running something like:
git config --global alias.st status
Enough pre-configuration for now. It’s time to checkout the SVN repository:
# Check out the SVN repository and set 'svn/' as
# prefix for the branches:
git svn clone -s --prefix=svn/ \
https://svn.tugraz.at/svn/$project foobar &&
cd foobar
# Adjust svn:ignore settings within git:
git svn show-ignore >> .git/info/exclude
# List all branches:
git branch -a
# List all remote branches:
git branch -r
# Rebase your local changes against the
# latest changes in SVN (kind of 'svn up'):
git svn rebase
# Checkout a specific branch:
git checkout $branch
Ok so far? But what do we have to do if we want to work on the upstream source and
are allowed to commit/push directly to the repository? Let’s see how to work on that without using branches:
# Hack:
$EDITOR foobar
# Check status
git st[atus]
# List diff:
git diff [foobar]
# Commit it with a commit message using $EDITOR:
git commit -a
# Now commit your changes (that were committed
# previously using git) to SVN, as well as
# automatically updating your working HEAD:
git svn dcommit
But what should we do if we do
not have commit rights? Let’s create our own branch and send a patch via mail to upstream:
# Make a new branch:
git checkout -b mikas_demo_patch
# and hack...
$EDITOR
# Commit all changes:
git ci -a -m 'Best patch but worst commit msg ever'
# ... and prepare patch[es]:
git format-patch -s -p -n master
# Now send mail(s) either use git-send-email:
git send-email --to foo@example.invalid *.patch
# ... or if you prefer mutt instead (short zsh syntax):
for f in *.patch ; mutt -H $f
You got a mail from someone else and would like to incorporate changes from the attached patch in your repository? Just store the mail in a seperate mailbox (use save-message in mutt for example, keybinding ’s’ by default), then execute:
# Apply a [series of] patch[es] from a mailbox
git am /path/to/mailbox
Want to work on a seperate branch and rebase your work with upstream?
# First of all make sure to use recent sources...
# So pull when using plain git:
git pull -u
# .. or when using git-svn use:
git svn rebase
# Then create a new branch:
git checkout -b mika
# Hack:
$EDITOR
# Commit:
git ci -a -m 'Best patch but worst commit msg ever'
# Switch to master branch:
git checkout master
# Pull again when using plain git:
git pull -u
# .. or when using git-svn use:
git svn rebase
# Finally switch back
git checkout mika
# Now rebase it with plain git using:
git rebase origin/master
# ... or when using git-svn:
git svn rebase
# Now check out the last 5 commits:
git log -n5
Another branch-session might look like:
git co -b foo
$EDITOR
git ci -a -m 'foo changes'
git co master
git co -b bar
$EDITOR
git ci -a -m 'bar changes''
git co foo
git rebase bar
git log -n5
git st
git branch
Pfuhhh? Right.
Now it’s time to check out another cool feature:
git stash, which is just great when
pulling into a dirty tree or when suffering from
interrupted workflow. Demo:
git stash
git pull / fetch+rebase
$EDITOR # fix conflicts
git commit -a -m "Fix in a hurry"
git stash apply
git stash clear # unless you want to keep the stash
git reset rocks as well:
# List all recent actions:
git reflog
# Now undo the last action:
git reset --hard HEAD@ 0
How to get rid of branches?
# Delete a branch. The branch must be fully merged:
git branch -d remove_me_branch
# Delete a branch irrespective of its index status:
git branch -D remove_me_branch
# Delete a remote branch:
git push reponame :branch
Repack a git repository to minimize its disk usage:
git pack-refs --prune
git reflog expire --all
git repack -a -d -f -l
git prune
git rerere gc
Use
git cherry to find commits not merged upstream.
Another really cool feature is the interactive rebasing:
git rebase –interactive
Make sure you are aware of
gitk:
… and don’t forget to set readable fonts for gitk, like:
[ -r ~/.gitk ] cat > ~/.gitk << EOF
set mainfont Arial 10
set textfont Courier 10
set uifont Arial 10 bold
EOF
If you prefer a Qt based interface check out
qgit.
Useful ressources:
I'm pleased my home state of Queensland (which bills itself as the Smart
State) has finally decided to start
fluoridating its water, a move the rest of the country made back in the
1960's and 1970's.
Hardly surprising I guess, when the No campaign for a referendum on daylight
saving involved a fear of the curtains
fading from that extra hour of sunlight...
I remember when I was little, my Mum used to give me fluoride tablets.
Dentists to this day, who have known I've grown up in Brisbane, have
remarked how they can tell by my teeth that I've had fluoride as a kid.
Apparently ones teeth are noticeably different (for the better) if fluoride
has been involved.
* I was too tired to write this yesterday. Yes, it was very hectic day (but great fun!). Things started very well. Sam and Bubulle did great presentations (specially, 
* Congrats to 
I spend quite a long time to fully configure my new Thinkpad X60s laptop. This will be my work computer and i wish to use Debian Etch on it. Since it is for my job, i want to use a stable debian release. The aim of this laptop is to always have something that works -- to keep focus on my job.
The configuration was tricky because there is a lot of people reporting that everything works with this laptop, but not a lot of people describing problems they encounter. Here is a list:
Sound:
Like most things, the scale of decisions that have to be made by a person
or organisation fall across a wide spectrum. At one end, you've got the
fine-detail work: lines of code, individual config settings, IP addresses,
that sort of thing. This is crucial work, because it's this detail that
ultimately produces saleable results. Travelling all the way to the other
end, there's the "big picture" decisions: the "visionary" stuff. What
market segment will we target? What will we do (in large-scale terms)
to get there?
I am convinced that individuals naturally gravitate towards one end of this
spectrum or the other, depending on their psychology. While people usually
can work at all scales, they have a "most comfortable" point where they
work the most naturally. The further away from this point they are pushed,
the less comfortable and effective they are.
No level of thinking is better or worse than the other; they're just
different. While "large scale thinker" and "small scale thinker"
could be taken as being insulting, I certainly don't mean it that way.
I should point out that "Strategy" isn't (just) about setting goals. A
strategist isn't someone who comes out with grand pronouncements like "By
the end of next year this company should be providing telecommunications
services to 20% of the Fortune 500" without knowing how to get there.
That's not a strategist, that's a poor-quality management consultant.
People whose only skill is making vague pronouncements should just be taken
out and shot. They're not doing anything useful for anyone.
A strategist is someone who is good at planning the goal of "20%
of the Fortune 500". They're thinking about the big picture issues,
without getting bogged down in the minutiae. A tactician, given the job of
planning something at the macro scale, will chase some good idea down an
intricately detailed rabbit hole, and miss the other dozen or so large
issues that need to be considered. The strategist's planning needs to stop
at a certain level and let other people take on the detail work.
Conversely, a good tactician can focus on the individual details
without getting distracted by the big picture. A strategist put into a
tactical role will miss all the important minutiae because they're working
out how their little part fits into the big picture, instead of working out
how to make their little part work, in and of itself.
It's important, for individual happiness, to try and work out what level
you're most comfortable thinking at, and then trying to find a job that
puts you there. It's almost as important to make sure that the people who
are working at the more and less detail levels around you are equally
comfortable.
Take, for example, the micromanager. We've all either been there ourselves
or have heard multiple stories on the subject. I think the micromanager is
nothing more than a person who wants to work at a smaller scale than they're
being forced to by their organisational rank. Since they can't do
the detail work any more, their only outlet is working vicariously through
their subordinates. Voila! Instant micromanagement.
An even more painful case of micromanagement would be when the subordinate
wants to think at a larger scale than the superior. In that case, the
subordinate will naturally be thinking large scale, and will miss the
details. To the small scale thinking superior, that is incompetence, and
will naturally be dealt with by more micromanagement. In reality, both
parties are incompetent at their jobs, and they should really swap roles,
so that everyone is in their element.
It would be nice if companies stopped thinking hierarchically in this way
-- that a more "senior" person has to think at larger levels. Just because
you've been somewhere longer (or have been working in an industry longer, or
got higher marks, or whatever), it doesn't mean that you're more of a
strategist. This is probably the Peter Principle restated: people get
promoted to a level where they just can't comfortably think at the necessary
scale any more. If instead people were put into a planning hierarchy based
on their natural scale of thinking, we'd all be a lot better off. There'd
be a lot less power games, though, which makes me think it's not going to
happen any time soon.
A business, at whatever size it might be, needs an appropriate mix of
strategists and tacticians. A really small business (1-10 people) can get
away without needing large scale thinkers, in the same way that a really
small boat can get away without needing a rudder or pilot. If a really
small boat gets itself into trouble, everyone on board can grab an oar or
bucket and help get the boat out it's predicament -- it's small and nimble
enough to be able to do that.
As the company expands, though, it's important to make sure you've got some
strategists around. If you don't have anyone to keep an eye out for
problems and plan around them, your small-to-medium sized boat is likely to
have a hole punched in it by a submerged rock. Even if somebody on board
happens to notice the rock before you actually hit it, once you get to a
certain size you can't physically stop or turn the boat in time.
If you don't understand the growth issues in the company, you might not
even realise that you're no longer the nimble and low-inertia dinghy until
you're up to your knees in sea water.
Although an obvious solution to this problem might be to say that all
businesses should be small and nimble ones, it's as impractical as saying
that all boats should be dinghies. A fleet of dinghies isn't going to be
able to support the worldwide sea freight market, and a fleet of small
companies doesn't have the necessary resources on hand to take on the big
projects that are so often needed. Also, a dinghy is at risk of being
swamped by one freak wave, while a larger ship can weather significant
storms without going under.
Regardless of the size of the business, there always needs to be a good
supply of tacticians. A boat (of whatever size) full of people who are all
looking out for rocks isn't going to go anywhere, because nobody's making
the thing move. Similarly, a company full of strategists isn't
going to be doing any of the day-to-day work that actually earns money, and
no money means no company.
The single most important thing, though, is be self-aware enough to know
what sort of person you are, and try to find something that lets you work at
the level you're most comfortable at. Otherwise you're just setting
yourself up for unhappiness.
I have been working recently working on the 
I'm organizing a micro-
It was a very long time ago since I did my last resume and never found the energy to update (or translate it to English) so I thought it was nice to have this kind of information about myself. It was nice since it gave to me a nice impressions of events I participated and like.
I’ve decided to do my resume using LaTeX (I use it for majority of my documents) and started to browse the web to find something useful to use as basis. I ended up finding 
I ended changing Adrew’s style to a class and writing a cuple of Makefiles to automate all this. All well done 
I suggest that anyone interested on it to take a look on the 
Patents are the best way to improve development, and software inventors have just the natural right to their algorithms and designs. Research and Development in industry wouldn’t just work without patent protection, and technology improvements would just stop, right?
Well, I’m not so sure of that.
Key 
For various reasons, I need to secure access to some resources using two-factor authentication, and thus have been looking at smartcards. These little devices store digital keys and certificates, protected by a passphrase, and calculate digital signatures on-device. Hence the two factors: possession of the card, and knowledge of the password.This sort of scheme is widely used by government agencies and large corporations (and largely reliant on Windows, too), but I wanted to find the low cost way in for the small operator using open source.
rebuildd-job stats says that 20 % of the archive is now built in less than 24h, seems fast, cool.
Bad point is that I'm building and trashing logs into /dev/null because I've no QA idea to implement right now.
My migration to mercurial is now complete. I've completed the last step, which was the migration of all the $foo-commits mailing lists.
It is at times like this that I remember two things:
