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 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 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.