Pre Scriptum: I do not advocate supporting many hashing functions just for the heck of it, but I don't like the "full sweep" approach _when_ (not "in case") we _need_ to change the hash function. After all, currently we have to operate with the fact that the next one will likely fall victim of attacks in time as well and this is going to be periodical operation. Dear diary, on Sat, Aug 19, 2006 at 05:19:31AM CEST, I got a letter where linux@xxxxxxxxxxx said that... > So you can get silly things like the need for a merge commit to > record the merge of trees that are actually identical. You can create an ordering of hashes based on their strength and then rehash your objects to max() of hash types used in the operation. So, if you're about to merge md5(x) and sha1(y), you first recompute the first id as sha1(x). Of course "recomputing" needs to be a wee bit more complex: you need to first substitute tree id for a common hash as well (and recursively do the same in the trees); slow, yes, but you can cache it. It gets worse when you are about to recompute ancestry, so you need to set up the hash usage transition so that you don't ever have to - such an event is sufficiently rare that each branch keeper can declare a flag day "before now I merged only md5 commits and from now on I will merge only sha1 commits". The tool can help to enforce this. This strategy will not help in 100% of the cases (md5git-based tool takes sha1git-created commit and re-creates it based on a snapshot and the precise same metadata) but I guess it's good enough. It's good that this is just theory so far, though. I'd say let it be for now (at least from the "emergency hash switch" standpoint) and do it when it's needed; you will have to have people upgrade their Git at that point anyway and the code would bitrot just sitting there and adding so-far unnecessary complexity. We have worse problems at our hands right now anyway. -- Petr "Pasky" Baudis Stuff: http://pasky.or.cz/ Snow falling on Perl. White noise covering line noise. Hides all the bugs too. -- J. Putnam - 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