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 - 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
