On Tue, Apr 09, 2013 at 08:03:24AM +0200, Johannes Sixt wrote: > Am 4/8/2013 23:54, schrieb Jeff King: > > Yeah, it would make sense for filter-branch to have a "--map-commit-ids" > > option or similar that does the update. At first I thought it might take > > two passes, but I don't think it is necessary, as long as we traverse > > the commits topologically (i.e., you cannot have mentioned X in a commit > > that is an ancestor of X, so you do not have to worry about mapping it > > until after it has been processed). > > Topological traversal is not sufficient. Consider this history: > > o--A--o-- > / / > --o--B--o > > If A mentions B (think of cherry-pick -x), then you must ensure that the > branch containing B was traversed first. Yeah, you're right. Multiple passes are necessary to get it completely right. And because each pass may change more commit id's, you have to recurse to pick up those changes, and keep going until you have a pass with no changes. But I haven't thought that hard about it. There might be a clever optimization where you can prune out parts of the history (e.g., if you know that all changes to consider are in descendants of a commit, you do not have to care about rewriting the commit or its ancestors). -Peff -- 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