Re: [PATCH v2 5/5] Reftable support for git-core
- From
- Martin Fick <mfick@codeaurora.org>
- Date
- Jan 28, 2020, 15:36 UTC
- Message-ID
- <2215899.n3y15ba4yI@mfick-lnx>
- In-Reply-To
- <20200128073100.GA563058@coredump.intra.peff.net>
On Tuesday, January 28, 2020 2:31:00 AM MST Jeff King wrote:
Show 26 quoted lines
> 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