Re: [PATCH] Add git-filter-branch

[Johannes Sixt <J.Sixt@eudaptics.com>]

Johannes Schindelin wrote:
> On Mon, 4 Jun 2007, Johannes Sixt wrote:
> > 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?
> 
> Are you actually sure that this scenario makes sense? When is the last
> time you wanted to filter a branch?

Oh, this makes a lot of sense. For example after I've imported a CVS
repository I had installed grafts for a number of merges that were made
in CVS (but we all know that CVS doesn't record them, so I did that
manually this way). That would be the merge commits in 'next' of the
example above. Now a simple

   git filter-branch -k master new-next

could "implant" the grafts into the commits. In this scenario I don't
need to rewrite 'master' because I know in advance that nothing would
actually be rewritten.

(Since 'master' was about 8000 commits I really didn't want to wait
until the no-ops would be completed, so I did it by actually fixing
cg-admin-rewritehist to not complain about the unmapped parents.)

> In any case, for such a degenerated test case I would rather try to limit
> filtering in the filter expression. Remember: you don't have to change
> _every_ commit.

I don't think that this is a degenerate case. See the example above.

Please observe that the only reasonable way to limit the commits to
rewrite is by giving some --not arguments to the rev-list. The filter
scriptlets themselves have no easy way to tell whether a commit should
be rewritten or not. They just rewrite - with the final result perhaps
ending up identical to the original; but no labor was saved.

-- Hannes