Subject: Re: [PATCH v2 5/5] Reftable support for git-core

From: Martin Fick <[email-masked]>
Date: Tue, 28 Jan 2020 08:36:53 -0700

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