Re: commit-message attack for extracting sensitive data from rewritten Git history

[Jeff King <peff@peff.net>]

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