Scott, I would have expected a little more from you than
your previous post
on why you chose bazaar!
Update: my initial post was offensive towards Scott, so I edited it
a little, following a good discussion with Scott via Email. Even though his
post didn't make it explicit, his post was meant to be a reaction to someone
else praising Git above everything else. Or, in his words:
You're responding with a defence of git because I posted a defence of bzr in
response to championing of git.
I decided to leave most of the original post untouched, nevertheless, but
please read it in this context. I guess the sensible conclusion is (as
always): to each their own.
Inline updates are enclosed in [brackets].
Git is less of a version control system than it is a filesystem and a means to
communicate among developers, and when used in that sense, it's extremely
powerful and intuitive to use. And it is also a version control system, like
Bazaar.
It's blazing speed isn't the only killer feature. By no means, however, is it
"heavily optimised for the 'I only apply patches' development model, at the
expense of ordinary development models" [anymore]. It also supports
centralised workflows just as well as it supports distributed approaches, and
you can switch between them [this is not really true when compared to how
Bazaar mimiques CVS/SVN behaviour; Git cannot do that].
Here are the git commands needed to do the same things Scott showed off in
your post:
$ cd myproject
$ git init
$ editor .gitignore
$ git add . # git rm ...
Let's branch before we commit.
checkout -b is a shortcut to create
a branch (
git branch myproject-foo) and immediately switch to it (
git
checkout myproject-foo):
$ git checkout -b myproject-foo
$ git commit
Git keeps all branches within the same repository and lets you switch between
them. Now,
that is a killer feature: whether I'm versioning code or stuff
like webpages, I often have external pointers to my code. For instance, I may
have
libfoo as a sibling of
foo-ng and the latter refers to
libfoo
in the
Makefile. If I wanted to try a new approach in
libfoo, I'd have
to change
foo-ng's
Makefile to point to
libfoo-newbranch instead,
or juggle directories around. That sucks. With git, I just checkout
a different branch in the same space:
$ git checkout master
And even better: if you don't like it, you
could just as well copy the
repository to create a separate (remote) branch from which you can later pull
or cherry-pick changes to the main branch:
$ git remote add foo ../myproject-foo
$ git fetch foo
$ git merge foo/master
Now back to your steps, and I'll stick to the git way of branching. Note how
git does not differentiate between pulling and merging in the sense that you
do. If there are no local modifications, git just fast-forwards the branch
with the commits on the master:
$ git merge myproject-foo
Even better, say you don't want the last two commits:
$ git merge myproject-foo~2
Unless git can fast-forward, it also treats a merge as a single commit and the
ancestry information allows you to inspect its component commits just like you
would.
gitk is another killer feature,
which I believe bazaar copied from git, just like the bazaar folks adopted the
concept of rebasing, which basically lets you rewrite history quite freely,
another killer feature (which can be quite badly abused if you don't know what
you're doing). And then there is
git bisect and
git-svn and
git filter-branch and
git describe and
git stash and
gitweb
and, and, and
So if I compare the git commands I used to the way you used bazaar, I fail to
see much of a difference. Do you?
It is true that git comes with an astounding number of additional commands,
most of which you never have to use, but which are available to the user [but
its interface is a
huge improvement over GNU arch, nevertheless, and if only
because the commands are named more logically and revisions and branches do
not have to adhere to one of the strangest syntaxes ever].
I don't deny that their sheer abundance is overwhelming and confusing at first
(a general rule for Git for beginners seems to be just to ignore ever command
with a hyphen in it). But once you get out of the newbie stage (it took me
about two weeks, the duration of
Debconf7 to
become an acquainted git user; in fact, David Nusinow
placed me among the
ranks of real git wizards Pierre and Keith before the conference was
over) arghs, I hate long remarks in parenthesis; once you leave the newbie
stage, you'll appreciate all these commands, which make it really easy to
script complex tools with git, making any plugin architecture pretty obsolete.
Finally, I found myself trusting git way more than any other version control
system I've tried simply because it's so transparent and you are
allowed to
edit stuff under
.git, which is mostly plan text files (and objects, which
you [could but] don't have to touch). It's transparent, and it stays true to
the Unix way of letting small tools do their jobs instead of the monolithic
approach.
NP:
Enchant:
Tug of War
Update: Carl Worth has a similar
beef with people thinking that Git is
too complicated and has
ported a chapter
from a book on Mercurial to Git to show
how that's not the case. It's a good read.
Update: Scott replied (quoted with permission), and I include my replies
inline:
"I can tell you why you chose bazaar: because you had to, because you are
being paid to use it."
Sorry, that just isn't true.
I'm paid to lead the Ubuntu Desktop Team; this has nothing to do with
version control, except that the various upstreams and packages use
different systems.
I am sorry about this accusation. It was low.
You appear to miss my point about Git, or maybe I didn't make it strong
enough. It's not that I don't understand it; it's that I had to take
time and effort to understand it.
And I've noticed that every reply to my post misses out the fact that
with Git, you have to take action to ensure your changes are actually
incorporated into the commit; either with git add or commit -a. This
exactly the kind of anti-social behaviour that I have issues with.
Well, Git people call this a feature and it
is very handy, but I see your
point. There is no way to configure
git-commit to always include
-a,
so you'll have to work around it:
git config alias.ci 'commit -a'
This creates
git ci to do exactly what you want. You cannot overwrite
commit that way though. But it could be trivial to add a configuration
option to
git-commit, if you think that the way that Git exposes the index
is an adoption-stopper:
$ file -L =git-commit
/usr/local/bin/git-commit: POSIX shell script text executable
Your post also introduces yet more over-complication by demonstrating
about making a branch (in an empty branch) before you commit.
Your post does the same ("A common operation is realising that the commit
you re about to make should really go on a new branch for now"), which is why
I did it. You don't
have to do that at all.
(Side-bar: bzr's design also permits multiple branches
within the same repository.)
So I read the manpage and found
bzr init-repository, but no way to add
a branch to an existing clone, and also no way to switch between branches
within a clone.
In your original post, you claimed: " Bazaar s command set works the way you
do." Well, the way I work is by "switching" between or "checking out" a new
branch in-place, but I could not trivially find the command to do this. This
is probably because I have not invested enough time into understanding Bazaar,
but isn't that what your claim is all about: that "[you] had to take time and
effort to understand [Git]" and that Bazaar just works for you?
My post was why I choose bazaar, and why I have rejected other
revision control systems that I have attempted to use.
So why did you post it? Surely because you wanted to express your preference
over Git. In doing so, you made a couple of claims about Git which are simply
untrue, which is why I replied. And the reason I replied is simply because
other people who try to make a choice between Git and Bazaar may find your
post and take away from it the information that Bazaar is superior to Git,
which it is not.
I'm glad that you prefer a different system; but please don't insult me
by suggesting that I'm being paid to use the one I prefer, or that I
haven't bothered to learn one I'm "slagging off".
But you did slag Git in that you basically present its shortcomings
side-by-side to Bazaar's greatness, which is a common PR/marketing thing to
do. So just like I failed to create an in-place branch above because I did not
bother to learn Bazaar, you did not bother to learn how to do with Git what
you showed off with Bazaar, or else I'll have to assume you would not have
written up the comparison as you did.
I have to use git as much as I use bzr, and I simply prefer bzr.
That was not the message I took from your original post.
On Wednesday 17th October the majority of my belongings will leave
Norwich, to arrive in Castlerock at some point the next week (exact day
to be confirmed). I will then start work for 3par
as a software developer in Belfast on Monday 29th. It's been 6 years
since we moved to Norwich and I'll be sad to leave it, and all the
friends I've made here, behind. I'd have stayed a bit longer but 3par
were keen for me to get started. I imagine I'll be in the
Fat Cat on Saturday 13th if people are
around. And I expect visited in NI once we get settled in!
Adrian (also sent by email):
I spent the better part of the weekend with trying to get an older Athlon XP mainboard to boot grub from an USB stick.
Unfortunately, without success.
Since a few months, my notebook boots Windows XP when it is booted naively. Only if the correct USB stick is plugged in
on boot, the Debian system that I work with comes up. The USB stick has grub, a kernel and an initrd which is used to
boot and unlock the crypto file systems (crypted LVs) on the disk and can be removed once the system has booted.
I wanted to use the same scheme for a “newly built” new desktop from old parts. Unfortunately, this was
much harder than I expected.
Since a few years, I use the USB-ZIP format for USB sticks that need to boot. It has shown that this format has the
best chance to successfully boot. For more information about this format and about how to build it, see
/usr/share/syslinux/README.usbkey on any recent Debian system with syslinux installed.
My grml USB stick that I always have on me is formatted like this, and the “new” desktop boots it just
fine. The boot stick for my notebook is an USB-ZIP as well, only that its primary partition is not FAT, but ext3.
Unfortunately, the BIOS of the “new” desktop seems to refuse booting grub. Neither my notebook’s
stick nor the new stick even come to the “loading stage x” output of grub, let alone to the menu. syslinux
works fine, and both sticks boot just fine on my notebook and on a qemu on the “new” desktop.
Since the grub command line has saved me multiple times in the past, I didn’t really like the idea of having to
use syslinux, and decided to boot the “new” desktop conventionally from hard disk without the use of an USB
boot stick. Until I got this far, the complete saturday and the better part of sunday was wasted. Darn.
This reminds me of a mainboard from 2002 (incidentally from the same vendor), which checked whether the first hard disk
had an active primary partition on it before it even tried to execute the MBR code. If no primary partition was found
(which was common case with the partitioning scheme that I used back then which only had logical drives - this was
before I discovered LVM), the BIOS gave the error message “Not found active primary partition” (sic!) and
refused to boot. Stupid programmers trying to outsmart the sysadmins of their products. But at least, the error message
was reasonably clear back then.
Yesterday, New Zealand crushed Romania (85-8), just like they crushed all other
teams they faced up to now. Of course, my only hope is that they stop
crushing teams...as France is very likely to be the next one. Indeed, the
only question about New Zealand is about their defensive skills as all teams
they faced scored one try against them. Particularly, their wing players
seem to be pretty "weak" in defense ("weak" in terms of New Zealand...:-)).
I haven't seen anything of Australia-Canada (37-6). Apparently, the
Australians were pretty quiet (6 tries, still!).
Very unfortunately, I haven't seen THE match between Fiji and Wales (38-34).
The Fiji team created an "half surprise" by qualifying for 1/4th finals. All
reports I read talk about a wonderful match, with great indecision, a full
commitment by both teams, and 9 tries. Sigh. I screwed programming my VCR
and we were strongly disappointed this morning.
Finally, Scotland managed to qualify after beating Italy 18-16. Up to the
very last minute, Italy hoped to qualify but Chris Paterson scoring 6
penalties out of 6 attempted converted all occasions the Scots had to score
points. I'm slightly disappointed for the Italians who played great games
all along this World Cup and would have deserved to qualify and meet
Argentina, France or Ireland.
Today, the final 2 teams for the 1/4th finals will be determined. Argentina
has great chances to finish first (they only need one bonus point) and meet
Scotland. France needs to win against Georgia. Scoring the bonus point would
secure the qualification for them. Ireland has little chances to qualify as
they need to beat Argentina without Argentina to score a bonus point,
therefore with more than 7 points difference. The most probable ticket is
Argentina finishing first and France 2nd (thus meeting New Zealand).
Randomisation is a good thing for media players, but it must be done properly.
What do I mean by this? I mean randomness which only works going forwards.
As an example consider the case where you have several films/videos in a directory and you run this:
In addition to the 
From the 
pioneered the term “corpse food” for eating meat. I believe that the term is accurate and should be used. If you can’t stomach eating corpses then there are many good vegetarian options available.
There are many vegetarians in the Linux community. As these issues are getting discussed a lot recently maybe it would be good to have the vegetarians choose some good vegetarian restaurants to have Linux meetings on occasion. Davyd got a bit of negative feedback on his post, maybe if he invited a bunch of his local Linux people to have dinner at a vegetarian restaurant and they enjoyed the food then the reaction to such ideas would be more positive.
Your 
I’ve been so busy lately that I forgot to write about it: 
Like any sensible software developer, I have a close relationship with revision control systems. In my previous job, I was an SCM Engineer (see