Sanitizing a branch

[Stephen J. Turnbull]

After writing this post, it occurred to me that the obvious
possibility would be to factor the cruft out as a loom.

http://bazaar-vcs.org/Documentation/LoomAsSmarterQuilt
https://code.launchpad.net/bzr-loom/trunk
lp:bzr-loom

Viktor Nagy writes:

 > I'm not sure, but couldn't bzr split work?
 > $ bzr help split
 > Purpose: Split a subdirectory of a tree into a separate tree.
 > 
 > So moving the "non-craft" to a subdirectory, committing it, and then
 > splitting it off might do what you want.

That would screw up interaction between the public branch(es) and the
private branch(es) unless he's willing to completely reorganize on
those lines.

 > >> I'd now like to make a public branch of this repo with the
 > >> public branch having none of the cruft but keeping the cruft in
 > >> my private branch and still have the ability to merge between
 > >> the two relatively painlessly.

By cruft do you mean "commits", or do you just mean "files", or do you
mean "bulk"?  If it's just the files that need to go, just make the
public branch and delete them.  If you want to get rid of commits or
repo bulk, though, you'd need to work harder.  (And it wouldn't help
the merge complexity, though it shouldn't make it worse.)

It should then be possible to cherry-pick the appropriate changesets
across.  You'll need to be disciplined enough not to touch cruft and
common content in the same changeset, and a regular merge presumably
won't work not only because the merge isn't quite smart enough, but
also in principle: you will be touching both cruft and common code,
and bzr doesn't have a way to tell the difference.  (I guess
theoretically it could if the cruft is well-factored into separate
files.)

 > > You need to replay your history to get the clean public branch
 > > but in the same time keep file ids as in your original
 > > branch. fast-import does not keep file-ids (yet?)  and in rebase
 > > it's not easy (possible?) to filter out cruft.

So export a fastimport database, import to git, do the history etc
munging in git using filter-branch, then import back to bzr.  Long way
round may be the fastest way home!  Unless bzr doesn't yet support
importing multiple branches in one fastimport?  (I haven't tried it
yet; I've stuck to the MacPorts and Gentoo packages so far.)