Each time when I have to use Bazaar I feel sick. It takes hours to do things which should not take more then few minutes. Let’s start with today problem and compare it to git.

I finally got [armel-cross-toolchain-base](https://launchpad.net/ubuntu/maverick/+source/armel-cross-toolchain-base) to build with non-sysrooted binutils. It required adding one patch and building binutils twice (once with sysroot for use during build, second without to put it in Ubuntu archive). After whole work I had 2 files to add, 3 hunks of changes in debian/rules and that’s all.

So I used “bzr add” on new files and “bzr commit -i” to select which hunks goes into which commit and repeated it until all changes landed in local branch. But then I discovered that I forgot to add 1.51 version into debian/changelog file before whole that work. So I did it now and next commit added 1.52 version.

And this is when whole “fun” started… I wanted to move r131 (the one with 1.51 changelog entry) to be before r128 one. With git it is just a matter or “git rebase -i” and whole work is done. But this was bzr…

“bzr rebase” command (part of “bzr-rewrite” package) supports only rebasing on top of other branch. But it was also useful as my branch was a bit out of sync with upstream one. So I started to ask questions on #linaro channel as Zygmunt was there and his knowledge of Bazaar was a big help in past. There were few ideas and I did some reading in meanwhile.

One solution was “use pipelines” and you know? They even works but then I needed to cherry pick one commit (r131 one). The only way which I found was “bzr merge -r130..131 :first” and I got all changes but not changeset. Right, git users, you **have** to commit after merge (and use “bzr log” to find commit message). And when you try “bzr merge” for few revisions they will be squashed… So finally what I did was merging changeset by changeset and commiting with original commit messages. Good that it was just few of them.

So after more then 10 minutes (“git rebase -i”) I finally got branch ready to be pushed. Next time I will spend that time on checking what is wrong with [git-bzr-ng](http://github.com/termie/git-bzr-ng) plugin as this will give me working two-way handling of Bazaar repositories without touching “bzr” command.

Bazaar — what is wrong with it?

5 thoughts on “Bazaar — what is wrong with it?

  • 7th October 2010 at 22:30

    I would have thought that making a new branch starting at r127, then doing ‘bzr rebase -r131 ../other’ then ‘bzr rebase ../other’ would have done the job. Did you try that, or did it fail? Perhaps it does work but needs to be more obvious in the rebase docs.

  • 7th October 2010 at 22:41

    Still don’t understand git people’s obsession with wanting a clean commit history. Surely leaving it how it was done just makes more sense and is more true? In any case, using bzr uncommit would have helped, I think.

    • 8th October 2010 at 09:16

      I also don’t understand why git users are so eager to rebase. History has taught us that rewriting history is dodgy. I am curious to more deeply understand the use cases that lead git users to want this functionality, though, because it’s always seemed like busywork to me.

      • 8th October 2010 at 09:41

        OK, let me then explain why I rewrite history.

        During years of my SCM use most of it was with OpenEmbedded build system. From time to time I had large sets of changes to be added and always was ordering it in a way that if something does not work with HEAD (due to my changes) then reverting to HEAD~1 ~2 etc was a method to check what is going on. On-push order was many times different then on-commit one.

        With code which took me to writing this post it was like: if 1.52 version can not be accepted then just revert few last revs to get 1.51 which was just bug fix needed for archive. I probably could create two branches for merge — one with 1.51 and then second with 1.52 but that’s sounds bad for me.

        @Neil: “bzr uncommit” is not a command which I like as this drops commit. Anyway the “bzr merge” way which I used was nearly same as it would be with “bzr uncommit”.

        • 8th October 2010 at 10:14

          Marcin, thanks for explaining. In cases like that I’ve tended to break the changes into branches, so that the merge (or unmerge) of a branch is a coherent unit of change and the underlying revisions for the branch don’t really matter. I guess this just fits my head better than trying to change revision history.

Comments are closed.