Martin F. Krafft: Uninformed slagger
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 commitGit 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 masterAnd 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/masterNow 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-fooEven better, say you don't want the last two commits:
$ git merge myproject-foo~2Unless 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 am sorry about this accusation. It was low."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.
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.
I use a rather simple CRM114-based setup to handle spam in my incoming mail.
Nothing really funky here as I essentially used examples from the Debian
package's examples/ directory.
The only personal touch is using a two-step method for this.
All mails are received on my home server and delivered to the "bubulle" user
there. A non aggressive CRM114 setup runs there for this user.
Mails identified as spam are sorted in a specific
folder on the server and are theoretically examined regularly. Indeed, this is
something I can't do anymore, given the number of identified spams (about
1000 per day, most of them in Debian mailing lists and Debian BTS). After a
quick look, this spam is re-teached as being spam to CR114, then stored as
backup in a giant mail folder, which allows me to retrieve a possible false
positive later.
All other mails are left in /var/mail/bubulle waiting for my laptop to grab
them.
This gives very few false positives, but still lets a lot of spam slip
through.
This is why I also run CRM114 on my laptop when mail is grabbed from my home
server (I use fetchmail between my laptop and my home server, wherever I am).
There, spams are again identified (more aggressively than what's done on my
home server) by CRM114.
The identified spams are sorted
in a folder which I routinely investigate carefully for false positives
(there are several a day, but the numbers are low because of the prefiltering
done on my home server). Spams are teached as spam to CRM114 and, of course,
ham is teached as "ham".
I recently added the following to my mutt setup so that SPAM/UNSURE/HAM
mails are easy to identify in mutt's index:
Hello World 
Today I found “
This is more of a reminder to myself to investigate this within GPE. The basic problem is that many events recorded in applications like gpe-calendar have a direct relationship with a specific person in the contact database and can also be linked to records in the expenses database. Expenses are relatively easy if the time of the expense occurring can be related to the duration of the event but a formal link may be more useful for extra granularity.
Your 
Last week I had to use Vicky's laptop briefly, which sadly runs Windows
XP. I was greated with this monstrosity:
The baby Jesus is beyond crying. For the curious, from left to right
there is battery charge, wireless network status, InstallShield Update
Manager, Java Updates, Windows Updates, Lastfm Scrobbler, Lenovo Client
Security Password Manager, Bluetooth network connection (never used),
Wired LAN network connection (never used), volume, ThinkVantage Access
Connections wireless status, IBM Message Centre, Epson printer status,
ThinkVantage Access Connections, Adobe Photo Downloader, GoogleTalk,
Bluetooth status, QuickTime, Windows Security Alerts. After 30 minutes of
removing software and disabling some more, I finally got this down to
seven icons. I wish there was a way to disable Windows from showing the
status of every network connection though.
NP: Sketches of Spain, Miles Davis
Observed simultaneously via 
I have a number of friends who are finishing PhDs and then I have those “special” friends who are wrapping up their dissertation and manage to do something else quite extraordinary right at the same time.