… 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:
… and don’t forget to set readable fonts for gitk, like:
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’m a developer, and my primary tool is my computer. Unfortunately, about 3 months ago, my computer died an untimely death, and I have resorted to using a pentium 200MHz machine with 256MB Ram, which lets me keep up with regular communications, but significantly slows the pace of development.
As a computer is a big purchase, and represents most of what I want to receive for the holidays, I’ve set up a 
The topic of a groupware with SyncML support is 
Andrew 
I just added all 
A curiously interesting thread has sprung up on the Xorg mailing list recently regarding the lack of bandwidth the developers might have for accepting patches. Bernardo Innocenti, who hacks on OLPC stuff amongst other things, wants to get some patches reviewed for acceptance, but there aren't enough people around with the time and inclination to review and accept his work.
He did a quick and dirty analysis of Xorg LoC vs Linux LoC, to give a "X codebase is roughly 1/2 Linux codebase" (which surprised me, actually, I'd always thought it was larger) and then a similarly rough analysis that suggests that Xorg has roughly 1/20th of the developer base.
To some extent Bernardo's metrics are arguable, but the basic facts are that Linux gets the lions share of the developers. Is this what we should expect? Is this a healthy way for the free and open source software community to support the development of what I personally would like to see as the future desktop base?
Linux does a fantastic job as an OS, right now. It's been doing it for years, really, but we still need to get behind some of the differential further up the stack. And all credit to those stalwarts of X development who are shouldering more than their fair share of the burden.
So if you were looking for an open source software project where you can be appreciated, don't overlook X.
These are all just 'first-builds' so problems could well lie ahead but I have now built a set of cross built packages for Emdebian (ARM) that edos-debcheck says is installable for a basic GPE installation. Only one package remains as a problem - gpe-filemanager builds fine but the current dependencies of libgnomevfs mean that gconf is required which doesn't give an option to disable ldap which is something I would rather do without. Certainly, existing GPE installations do without ldap but that could just be because these tend to use older versions of the particular libraries.
We got home from our week in Arizona late last night. We decided to drive
non-stop yesterday, and get home in a day, rather than split it over two days
like we did getting there. It ended up taking around 15 hours (we had an
unexpected delay at Lost Hills because we found a stray dog (we initially
thought it to be injured to boot) and Sarah was trying to get hold of some
local animal control people to do something about it), otherwise it'd have
taken closer to 14 hours.
The drive to Phoenix was pretty uneventful. We took our time leaving
Mountain View on Sunday (we had an early Thanksgiving dinner with all of our
neighbours on Saturday night), and decided to call it a night at Cabazon. For
about the same price that we stayed in a crappy motel 
Apparently some people worry that Gforge may be abandoned, or on the
verge of being superseded with the proprietary "Gforge Advanced
Server" rewrite. Let it be known that I for one have no plans to
switch to Gforge AS, for all the reasons you'd expect from a free
software user and advocate: I don't have access to the source code
(it's made illegible by some sort of industrial PHP obfuscator), I
can't hack it because the license doesn't allow me to, I can't audit
it for security flaws, I can't adapt it to particular needs, etc.
Since a significant part of my income comes from maintaining Gforge
instances for clients, with local modifications for their particular
needs, it's an economical necessity that Gforge stays free. And
evolving.
Right. Having said that, I guess I have to show concrete evolutions
in addition to principles and ideals. So what changed recently?
It's quite some time since I didn't blog about D-I i18n and the number of new languages we'll support in the next Debian version, lalala...
A few works are on their way, indeed:
Better than just a party, it s a bug squashing party! 
Rmetrics now comprosises over twenty individual packages. Eleven new
packages were added in the 260.72 release for R 2.6.0, and they required
eight other new packages from