On Mon, Sep 02, 2024 at 01:18:38PM +0000, brian m. carlson wrote: > On 2024-09-01 at 23:45:43, Patrick Steinhardt wrote: > > So we basically have three different options: > > > > - Accept that we just don't handle this case correctly and let the > > code error out. This pessimizes all hashes but SHA256. > > > > - Bail out when outside of a repository when `--object-format=` wasn't > > given. This pessimizes all hashes, but gives a clear indicator to > > the user why things don't work. > > This is what I would recommend. I'm also leaning into this direction. I want us to move to a world where SHA1 and SHA256 are equal citizens. We won't ever get folks to move on to SHA256 repositories when it continues to be an afterthought that behaves worse than SHA1 repositories. That's basically where this whole exercise to stop setting the default hash came from. GitLab nowadays has support for SHA256 repositories, so I want to ensure that it can be used as a drop-in replacement for SHA1 in basically all ways. > > - Introduce packfiles v3 and encode the object format into the header. > > Then do either (1) or (2) on top. > > I think we have pack v3 already (which is the same as v2), and v4 was > for an experimental format that never landed fully. Maybe v5? Ah, fair enough. > If you wanted to do this, you could add support for arbitrary chunks, > like with multi-pack indexes, that would allow for extensibility in the > future. However, you'd also need some protocol capabilities if you > want to send pack v5 or certain chunks over the protocol. > > > The last option is of course the cleanest, but also the most involved. > > I'd personally recommend just requiring the `--object-format=` option, > but of course if you want to write pack v5, don't let me stop you. Well, in the context of this issue I'd definitely aim for the easier fix first. Regardless of whether or not we introduce v5, we'd still have to address the underlying issue for repositories that do not (yet) have v5 packfiles. Patrick
