Johannes Schindelin wrote:
>
> Hi,
>
> On Mon, 4 Jun 2007, Johannes Sixt wrote:
> > 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.
>
> > 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
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
