Re: [PATCH] Add git-filter-branch

Johannes Schindelin wrote:

Hi,

On Mon, 4 Jun 2007, Johannes Sixt wrote:

quoted

I propose that you just get rid of the "seed" stance and don't fail if a
commit cannot be mapped - just use it unchanged (don't forget to adjust
the map() function, too).

It is as much for debug reasons as for consistency, so I'd rather keep it.
One more safety valve for catching bugs.

quoted

Then you can get rid of -r and use -k to specify everything you want
under "--not" in the rev-list.

Actually, -r is quite useful. It means "start rewriting with this commit",
and saying "--not <commit>^" is _not_ the same when <commit> is a merge.

But this makes only sense if you have a linear history. Consider this
history, where you want to rewrite the commits that are only on branch
'next':

--A--B--C--D--E--F--G--H       <- master
   \  \  \  \  \  \  \  \
    X--o--o--o--o--o--o--o--o  <- next

How would you go about with the current calling convention? It's
unpractical to say the least:

   git filter-branch -r X -k B -k C -k D ... -k H new-next

If you don't give all the -k, then you get the "assertion failed" error
because the parents B..H are not registered in the commit id map. This
is not something I'd like to try on a history like git.git's.

OTOH, rev-list can easily restrict the commits regardless of how many
merges there are in 'next':

   git rev-list next --not master

Why not use its powers?

-- Hannes