Sanitizing a branch

[Ali Sabil]

Hi,

Some time ago I needed to rewrite the commit messages of a project, so
I wrote a small filter-branch plugin for bzr. It doesn't implement
content filtering, but it might be a usable base for what you are
trying to achieve. You can get the plugin from here:

bzr branch lp:~asabil/+junk/bzr-filter-branch

Cheers,

--
Ali

2009/3/16 Viktor Nagy <viktor.nagy at gmail.com>
>
> Hi,
>
> 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.
>
> V
>
>
>
> 2009/3/16 Alexander Belchenko <bialix at ukr.net>
>>
>> Erik de Castro Lopo пишет:
>>>
>>> Hi all,
>>>
>>> I have a problem that is related to this one:
>>>
>>>   https://lists.ubuntu.com/archives/bazaar/2009q1/054149.html
>>>
>>> I have a project that was imported into Bzr from GNU Arch many years
>>> ago and has history dating back to early 2004. During the time I've
>>> hacked on this I have added all sorts of cruft including tests files
>>> scraps of documentation etc.
>>>
>>> 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.
>>>
>>> Is this possible? Any clues on how to do it?
>>
>> No, there is no ready to use tool.
>> The best match is fast-import-filter and/or rebase, but both fails to satisfy
>> your main requirement: "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".
>>
>> 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.
>>
>> You can try to do it manually with rebase, but it seems you have very big history,
>> so I suspect it'll be very long and boring process.
>>
>>
>