When makepkg updates a local Bazaar repository, it first checks if that local repository is "really a clone" from the remote repository specified in PKGBUILD. This check is buggy and I believe it is not necessary, because bzr pull does not try to merge commits. The pull command only succeeds if the remote repository contains all commits from the local repository.

For example, if you switch to a fork repository in PKGBUILD, and the local repository is a subset of the fork, next bzr pull will succeed to switch your local copy to the fork. If you then switch back to the original repository in PKGBUILD, then next bzr pull will fail anyway without manual checks, because the repositories have diverged. If the fork was not a superset of your local repository, bzr pull would have failed in the first place.

Therefore, no manual check is needed thanks to bzr pull. This is different from git pull, which may lead to merges, it seems. So it would be a mistake assuming equivalence between bzr pull and git pull. As shown below, this manual check has been added for git then copied without any reason for bzr. In fact, there is no such manual check for hg.

https://projects.archlinux.org/pacman.git/commit/?id=c926c39b0481ec3db931fff1f86db0c49d78976b
https://projects.archlinux.org/pacman.git/commit/?id=3b02f80dcb3159a7ab0c673d5eae971ad7504e7f

If those manual Bazaar checks worked, it would be simply useless code (unless there are cases where bzr pull is not enough). But they are buggy, as I explained in a proposed commit for MSYS2 pacman and which is reproduced in the mailing list thread below. Thanks Florian for the link to git commit. Allan, I hope to have clarified why bzr pull would fail. So I propose a patch like the one attached.

https://lists.archlinux.org/pipermail/pacman-dev/2015-January/019786.html