From: Johannes Sixt <j.sixt@eudaptics.com>
Date: Mon, 04 Jun 2007 16:34:53 GMT
Subject: Re: [PATCH] Add git-filter-branch
Message-ID: <46643F2D.7C896CBC@eudaptics.com>
In-Reply-To: <Pine.LNX.4.64.0706041711500.4046@racer.site>

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