obliterate functionality?

[Theodore Tso]

On Wed, Mar 19, 2008 at 06:39:28PM +0200, Giorgos Keramidas wrote:
> Probably not as convenient as 'git filter-branch', but the feature is
> already there.  The main point of grief whenever this issue comes up in
> FreeBSD developer meetings is that this forces everyone to rebase, but I
> don't see how this can be avoided.

You only have to rebase if you have any local changes.  And rebasing
really isn't that hard; in fact, in my development workflow for
e2fsprogs I'm rebasing all the time.  

I keep topic branches for each set of patches which I am working on,
and I often have multiple topics "cooking" at the same time.  So I'm
rebasing my topics branches all the time whenever I commit patches to
my master branch, and so if they're not ready to be merged into
master, I'll rebase them so that each topics branch is based off of
the lastest master.  That keeps the commit history much cleaner and
means that I'm sure all of the topic branches don't have any logical
or patch conflicts with the latest head.

Mercurial has the transplant extension which makes rebasing easy.  So
I'm not sure FreeBSD developers really needs to fear rebasing.  It
seems that a workflow that uses a lot of rebasing isn't as common
amongst Mercurial some users, so perhaps it's a bit more intimidating
to them, but it really isn't that hard.

If you have some merges in your local tree, you might have to redo
them, but for most workflows, where people tend to track the mainline
head fairly closely, that's relatively unlikely.

						- Ted