Re: [PATCH] Add git-filter-branch

Johannes Schindelin wrote:

On Mon, 4 Jun 2007, Johannes Sixt wrote:

quoted

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