bazaar Digest, Vol 80, Issue 44

[Stephen J. Turnbull]

Adrian Wilkins writes:
 > On 27/10/11 07:58, "Stephen J. Turnbull" <stephen at xemacs.org> wrote:
 > > I see.  So the only overhead here is the branch metadata (assuming
 > > you're in a shared repo).  And I take it that
 > >
 > >      bzr switch -r 42 -b newbranch
 > >
 > > creates a branch whose tip is r42 with the name "newbranch", [...]
 > 
 > Alas, this does not work at present, see :
 > 
 > https://bugs.launchpad.net/bzr/+bug/733225

Too bad, because that really is the killer app for featherweight
branching in my workflows.  Normally when I make a branch at the tip,
it's with malice aforethought, intending to work in anger on some
feature.  I would be willing to sacrifice a few dozen seconds to
create a new branch.

"Featherweight" only really matters when I spot a typo or something
like that.  Then it allows me to rewind to before the feature branch,
do the fix quickly, return to my main thread before I lose grasp of
it, and then recover, complete, and push the trivial change in the
featherweight branch at my leisure later.  Note that I don't even want
to waste time confirming that my trunk clone is up-to-date, etc.

I usually rebase/cherrypick them, and then nuke the temporary branch,
but a history-is-sacred fanatic could just as well merge.

This could easily be done with pipelines or looms (the latter is
overkill, I suppose), but when making a branch is as cheap as
touch(1), why bother with the heavy artillery of a whole separate UI?