… 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:
It's now far over a year that the ipw3945 driver doesn't work reliably for me
on stock Debian kernels. From other blogs I figured it only occurs in SMP
situation, and even then not on all systems.On my laptop, I can reproduce it rather reliably: connect to the WPA2 encrypted
network at my parents and transfer a file to one of the other computers on the
network. An IO rate of a couple hundred kb/s will make the wireless card
disconnect frequently. Often I end up having to flip the kill switch twice to
get it working again.I have however found a workaround: use a kernel with preemption enabled.So it seems that there is something in that driver which will in certain
situations trigger a big lock. Actually you can even hear that - sound will
also be interrupted shortly when the wireless dies. Without preemption enabled,
this will make the wireless card run into a timeout and reset itself.I don't know yet if this completely fixes it. But other comments in the
bug report at
bughost suggest that it's at least much more stable.
bug 1085 seems
another instance of this bug and is open since june 2006. As good as their OSS
record is, it seems that Intel has given up on fixing this bug.There are other drivers causing similar problems. For example the dcdbas driver
for the Dell Bios used to check for the wireless kill switch, display
brightness and such functionality. When I load that driver, hal or
NetworkManager will interrupt my sound every few seconds when polling the kill
switch. Maybe they would just need to get hold of a system affected so they can
diagnose it properly themselves. There have been at least 20 people reporting
this bug by now, most of them on Dell systems.
Today I went for the second time[1] to 
I think that all Debian developers (including the brand new ones) will be delighted to learn that we not only have 4 indian DD's now, but we have an Indian DPL, at least according to his own words after a few beers.
The first two days at FOSS.in have been quite busy. Sam's first talk ("Giving back to the community, how does Debian perform") was really interesting with ideas about a possible place where various distributions' patches to software could be collected and made available to upstream authors.
I then had two talks in a row, which I feared a little but went pretty well. The first one was a brand new for me ("Contributing to Debian for dummies"). I tried to enforce the idea that contributing to Debian might be fun and opened to everybody, not only deep hard-core hackers (I funnily took my friend Andrew McMillan as example for hard-core hackers....).
To make the talk less boring, I did choose to illustrate the various ideas I was explaining with photos taken from the various Debian-related events I attended last years. So, many of my Debian friends will recognize themselves 
)
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.
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 
I just went to a meeting where I received the results of the university admission exam I did some weeks ago.
A few days ago I installed the 
Andrew