5 ms·

Is there an explanation of what would go wrong with the naive approach? E.g.: - Change the binary file format in repos to support arbitrary hash algorithms, in

by ivoras 4y ago

Is there an explanation of what would go wrong with the naive approach? E.g.: - Change the binary file format in repos to support arbitrary hash algorithms, in a way which unambigously makes old software fail. - Increment the Git major version number to 3.0 - Make the new version support both the old version repos and the new ones. Make it a per-repo config item that allows/disallows old/new hash formats. In theory, there's nothing wrong with having objects hashed with mixed algorithms as long as the software knows how to deal with that. - The old format will probably have to be supported forever because of Linux. Most user-facing utilities don't care what the hash algo actually is, they just use the hash as an opaque string.

deleted 4y ago
[deleted]
runeks 4y ago
Releasing new software is the simple part. The problem is that versioning is lacking in the old software, and therefore it doesn’t know how to talk to the new software. So for the old software there’s no difference between “invalid data” and “I’m too old, please upgrade me”.
- dingleberry420 4y ago
  > So for the old software there’s no difference between “invalid data” and “I’m too old, please upgrade me”. And why is this an issue? Release the new version that can read new repo formats, but doesn't write them yet. Wait a year. Release new version that can write new repo formats and encourage users to upgrade. Anyone who hasn't upgraded in the past year probably doesn't care about security and should be left behind. Besides, once they google the error message they'll figure it out soon enough. It's not like git is known for its great UX anyway.
  - hamilyon2 4y ago
    I might be mistaken, but github could be using their own version of git and accompanying tools. So, unless they implement uprade themselves, no amount of waiting will make git interoperable with them.
    - dingleberry420 4y ago
      True, but they'll feel it in their pocket eventually when people move to alternatives that do support it.
kzrdude 4y ago
All of what you wrote, except the version bump, is already implemented. It's the nicer features that are missing, the nice migration path.
kelnos 4y ago
> In theory, there's nothing wrong with having objects hashed with mixed algorithms as long as the software knows how to deal with that. That's an interesting idea, actually. I'm not sure they plan to support that, though? That would make things a lot easier on existing repositories; without support for mixed hashes, repos would have to have their history entirely rewritten, which would invalidate things like signed commits/tags.
- rurban 4y ago
  No, study the transition document, please. there is one hash version, plus a translation table for the other format. no history rewrite. new repos will use the new hash. old repos will eventually fully convert to the new hash, then all old hash links after the transition period will become obsolete.

by ivoras 4y ago

deleted 4y ago

[deleted]

runeks 4y ago

Releasing new software is the simple part. The problem is that versioning is lacking in the old software, and therefore it doesn’t know how to talk to the new software. So for the old software there’s no difference between “invalid data” and “I’m too old, please upgrade me”.

dingleberry420 4y ago
> So for the old software there’s no difference between “invalid data” and “I’m too old, please upgrade me”. And why is this an issue? Release the new version that can read new repo formats, but doesn't write them yet. Wait a year. Release new version that can write new repo formats and encourage users to upgrade. Anyone who hasn't upgraded in the past year probably doesn't care about security and should be left behind. Besides, once they google the error message they'll figure it out soon enough. It's not like git is known for its great UX anyway.
- hamilyon2 4y ago
  I might be mistaken, but github could be using their own version of git and accompanying tools. So, unless they implement uprade themselves, no amount of waiting will make git interoperable with them.
  - dingleberry420 4y ago
    True, but they'll feel it in their pocket eventually when people move to alternatives that do support it.

kzrdude 4y ago

All of what you wrote, except the version bump, is already implemented. It's the nicer features that are missing, the nice migration path.

kelnos 4y ago

> In theory, there's nothing wrong with having objects hashed with mixed algorithms as long as the software knows how to deal with that. That's an interesting idea, actually. I'm not sure they plan to support that, though? That would make things a lot easier on existing repositories; without support for mixed hashes, repos would have to have their history entirely rewritten, which would invalidate things like signed commits/tags.

rurban 4y ago
No, study the transition document, please. there is one hash version, plus a translation table for the other format. no history rewrite. new repos will use the new hash. old repos will eventually fully convert to the new hash, then all old hash links after the transition period will become obsolete.