> O volbě hashovací funkce nikdy nemůže rozhodovat přispěvatel, to musí vždy udělat správce repository – jinak by to byla bezpečnostní díra
No, bezpečnostní díra samo o sobě asi ne, ale přinášelo by to komplikace. A souhlasím, že by to bylo nešťastné řešením.
Otázkou ale třeba je, jak moc automatizovaně se má přecházet. Nechat vše pod starou hashovací funkcí zní jako riziko, že spousta projektů nemigruje. Automatický převod na novou hashovací funkci zase zavání problémy s kompatibilitou, zejména pokud různí vývojáři budou mít různé verze Gitu… Není úplně sranda skloubit kompatibilitu, bezpečnost a automatický přechod.
Možná to dopadne tak, že v jedné verzi Gitu bude nová hashovací funkce pro ty, kdo si ji vyžádají, později bude automaticky pro nové repozitáře, později začne Git doporučovat přechod a po čase začne automaticky migrovat.
> staré commity budou dále dohledatelné i podle starých ID – které ale už nebudou mít funkci ID, ale jenom jakési poznámky
Takže by to fungovalo jako druhé id, jen by se preferovalo používání nového id. A vyžadovalo by to dva stromy, jeden sha1 a druhý s novou hashovací funkcí. Pokud by tu byl starý hash uložený jen jako poznámka, šlo by k libovolnému id commitu pod 40 hexaznaků vytvořit libovolný obsah repozitáře. Což by zde situaci oproti dnešku zhoršilo, dnes je potřeba vhodná kolize SHA1, což si klade jisté (nejen finanční) nároky.