| Message ID | 20200813224901.2652387-1-sandals@crustytoothpaste.net (mailing list archive) |
|---|---|
| Headers | show |
| Series | Documentation updates for SHA-256 | expand |
On 8/13/2020 6:48 PM, brian m. carlson wrote: > As was pointed out recently, some of our documentation doesn't properly > reflect the new support for SHA-256. Just to bring up some subtlety in Martin's message [1], there is some valid concern that the existing file formats are not correctly versioned "in a vacuum." When they are in a repository that has SHA-256 set as its hash algorithm, Git interprets these file formats correctly, but if a *.pack file (and its *.idx) happened to be copied into the pack directory of a Git repository still in SHA-1 mode, then Git would get confused and probably fail miserably. Is that really a concern? Maybe, but also Git will never move data like that. The main thing is to focus on compatibility of the .git directory as a whole (and the protocol, as we move into inter-operability mode). [1] https://lore.kernel.org/git/CAN0heSptiJL9d86ZeNPMUaZeTA68juwTyf3K-uWR=K-vt=1Hrg@mail.gmail.com/ > This series updates the pack and > index documentation to reflect that these formats can handle SHA-256, > and updates the transition plan to reflect what we've implemented and > what the next steps are. These patches are good to help clarify these formats in the new world. Thanks, -Stolee
Derrick Stolee <stolee@gmail.com> writes: > Is that really a concern? Maybe, but also Git will never move data like > that. I would say that we can safely say that this year ;-) as dumb HTTP would be mostly dead. > The main thing is to focus on compatibility of the .git directory > as a whole (and the protocol, as we move into inter-operability mode). > > [1] https://lore.kernel.org/git/CAN0heSptiJL9d86ZeNPMUaZeTA68juwTyf3K-uWR=K-vt=1Hrg@mail.gmail.com/ > >> This series updates the pack and >> index documentation to reflect that these formats can handle SHA-256, >> and updates the transition plan to reflect what we've implemented and >> what the next steps are. > > These patches are good to help clarify these formats in the new world. Yup.
On 2020-08-14 at 04:47:19, Junio C Hamano wrote: > Derrick Stolee <stolee@gmail.com> writes: > > > Is that really a concern? Maybe, but also Git will never move data like > > that. > > I would say that we can safely say that this year ;-) as dumb HTTP > would be mostly dead. We do fetch the refs first for dumb HTTP so last I checked, we correctly detected this case and failed. I'd personally be happy to let the DAV-based protocol die, but there are folks who like it.
"brian m. carlson" <sandals@crustytoothpaste.net> writes: > On 2020-08-14 at 04:47:19, Junio C Hamano wrote: >> Derrick Stolee <stolee@gmail.com> writes: >> >> > Is that really a concern? Maybe, but also Git will never move data like >> > that. >> >> I would say that we can safely say that this year ;-) as dumb HTTP >> would be mostly dead. > > We do fetch the refs first for dumb HTTP so last I checked, we correctly > detected this case and failed. I'd personally be happy to let the > DAV-based protocol die, but there are folks who like it. I didn't mean DAV. The oldest dumb HTTP code grabs all packfiles listed in objects/info/packs and there is nothing to prevent folks from running the current client to fetch from SHA-256 repository into a SHA-1 repository. The resulting packfiles that do not identify with the version number what hash it uses would be very hard to use.