Re: bzr repository ready?

[Karl Fogel <karl.fogel@canonical.com>]

David De La Harpe Golden <david@harpegolden.net> writes:
> As a git user, I've been trying to set up for emacs bzr tracking, and
> perked up a bit at your posts suggesting bzr could be more git
> like. With searching, I then found
> http://bazaar-vcs.org/GitStyleBranches
>
> So I've been trying to work out one thing in particular - is there a
> bzr analogue of the distinction between master and
> remotes/origin/master ? I'm a bit confused by bzr "trunk" seemingly
> serving some double duty as a remote tracking and local branch in
> setup guides so far, so my (possibly quite contrary) stab at setting
> up went like the below.
>
> I'm unclear on how to / if I should tell bzr that remotes-origin-trunk
> is a remote tracking  branch (bzr bind?)
>
> I /think/ bzr push --remember allows me to setup to push from my trunk
> to elsewhere while still merging from remotes-origin-trunk to my trunk
> (which I'd do after a bzr pull to update remotes-origin-trunk from
> origin trunk, by analogy to a git fetch) ?

I may misunderstand the question, but I think this will help you:

  * The names of branches are whatever their owners want to call them,
    and it doesn't matter if two branches have the same name.

  * 'bzr push --remember DEST means the next time you can just do
    'bzr push' and it will push to that same DEST.

  * Suppose you have local branch LB, related to (originally branched
    from) upstream branch UB.  After you send changes from LB to UB, you
    can pull from UB to LB and, of course, it won't send those changes,
    because LB already has them.  It will send changes LB doesn't have.

  * You could instead send those changes from LB to SOME_OTHER_BRANCH,
    and thence to YET_ANOTHER_BRANCH, and thence to UB.  If you did
    that, when you pull from UB to LB, there will still be no problem,
    and the changes won't get sent, because LB already has them.

  * There are ways that history can get sort of twisted up; however, the
    methods we are recommending for Emacs development avoid that.  See
    the oft-referred-to http://www.emacswiki.org/emacs/BzrForEmacsDevs.

The question of who is "remote" and who is not depends on point of
view.  I don't _think_ bzr has the concept of a remote tracking branch,
at least not one that is used very often; but someone who knows better
might follow up to correct that (I hope they will).

(Posting from my Canonical address, to see if it works reliably now.  If
you don't get this, please let me know :-) .)

-Karl