In git's case, by cryptographic agility I was imagining a Gitv2 which would produce SHA-256 hashes by default on new commits, and was able to still understand SHA-1 hashes on old commits so it could continue to read data produced by Gitv1 clients or Gitv2 clients in SHA-1 mode without needing an upfront convert-the-whole-repo step. Definitely less preferable than the alternative of just supporting SHA-256 from the very start though. May be less preferable to making git auto-convert repos forward to a new SHA-256-only version.