obliterate functionality?

[Marcin Kasperski]

Patrick Mézard <pmezard at gmail.com> writes:

> Giorgos Keramidas a écrit :
>> 
>> The lawyers don't really care if I have an old copy of user/keramida at
>> home, on my laptop, or archived in a DVD-ROM disk somewhere.  They are
>> only interested in making sure that the `Project' is not endorsing or
>> supporting a clone with the obliterated files.
>
> It's clear that no solution preserving the hashes is likely to come
> up quickly, it's breaking deep invariants which makes it hard to
> implement and it would break existing clients. What about discussing
> real-world use cases instead, so we can come up with better history
> rewriting tools ?

hashes routines work in a stream basis. I can imagine replacing
obliterated file with the information what was its hash and using this
value for further calculation

Say you had changeset [X][B][C] with sum N. X is to be obliterated.
So you just save the state of hash calculation after X is processed,
and since then just start calculation for B and C with different
starting value....

If it is [B][X][C], then you can preserve separately sum after B for
additional verification, then use the partial sum after B and X as
above.

(yeah, I know, that is just very looose idea, not sure how difficult
would it be to implement this)