On Tuesday, January 28, 2020 2:31:00 AM MST Jeff King wrote: > Some thoughts on compatibility: > > The idea of the config changes is that older versions of Git will either > complain about repositoryformatversion (if very old), or will complain > that they don't know about extensions.refFormat. But the changes you > made in patch 1 indicate that existing versions of Git won't consider it > to be a Git repository at all! > > I think this is slightly non-ideal, in that we'd continue walking up the > tree looking for a Git repo. And either: > > - we'd find one, which would be confusing and possibly wrong > > - we wouldn't, in which case the error would be something like "no git > repository", and not "your git repository is too new" > > So it would be really nice if we continued to have a HEAD file (just > with some sentinel value in it) and a refs/ directory, so that existing > versions of Git realize "there's a repository here, but it's too new for > me". > > There's a slight downside in that tools which _aren't_ careful about > repositoryformatversion might try to operate on the repository, writing > into refs/ or whatever. But such tools are broken, and I'm not sure we > should be catering to them (besides which, the packed-refs ship sailed > long ago, so they're already potentially dangerous). Could you elaborate on this a bit because it seems on the surface that these tools aren't very dangerous, and therefore likely many of them exist? What are the dangers today of tools that understand/operate on loose and packed refs without reading repositoryformatversion? -Martin -- The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation
