Which is exactly the way I would approach the problem. Refactor to a standard type, which is something which should have been done to start with, but anyhoo.
A true refactoring. ie. Improve the internal code quality without altering it’s observable behaviour, is definitely the way to go with this problem.
One of the next refactorings will be to create a further type. Something like objectidsha1…. and then go around changing some of the objectid’s to objectid_sha1 to reflect the fact that they will always have to be able to import and convert old repos.
I wondered about that next step. Are they going to store both a SHA-1 and some new hash? Is the object_id going to be a tagged union? Multiple incompatible types like you propose?
The
struct object_idis currently defined asso it’s still exactly the same thing and this is really more a refactoring in preparation of a different hash function.
Which is exactly the way I would approach the problem. Refactor to a standard type, which is something which should have been done to start with, but anyhoo.
A true refactoring. ie. Improve the internal code quality without altering it’s observable behaviour, is definitely the way to go with this problem.
Things will get interesting when they get to changing on-disk formats, fast export/import, pack files, etc.
Yup.
One of the next refactorings will be to create a further type. Something like objectidsha1…. and then go around changing some of the objectid’s to objectid_sha1 to reflect the fact that they will always have to be able to import and convert old repos.
I wondered about that next step. Are they going to store both a SHA-1 and some new hash? Is the
object_idgoing to be a tagged union? Multiple incompatible types like you propose?