Re: [PATCH 00/30] [RFC] extensions.refFormat and packed-refs v2 file format

[Derrick Stolee <derrickstolee@github.com>]

On 11/18/2022 6:31 PM, Junio C Hamano wrote:

> I have been and am still offline and haven't examined this proposal
> in detail, but would it be a better longer-term approach to improve
> reftable backend, instead of piling more effort on loose+packed
> filesystem based backend?

If reftable was complete and stable, then I would have carefully examined
it to check that it solves the problems at hand. I interpreted the lack of
progress in the area to be due to significant work required or hard
problems blocking its completion. That appears to be a wrong assumption,
so we are exploring what that will take to get it complete.

I am still wary of it requiring a clean slate and not having any way to
upgrade from an existing repository to one with reftable. I'm going to
reevaluate this to see how expensive it would be to upgrade to reftable
and how we can deploy that change safely.

These upgrade concerns may require us to eventually consider a world where
we can upgrade a repository by replacing the packed-refs file with a
reftable file, then later removing the ability to read or write loose
refs. To do so might benefit from the multi-valued extensions.refFormat
that is proposed in this RFC, even if packed-v2 does not become a
recognized value.

My personal opinion is that if reftable was not already implemented in
JGit and was not already partially contributed to Git, then we would not
choose that format or that "all or nothing" upgrade path. Instead,
incremental improvements on the existing ref formats are easier to
understand and test in parts.

But my opinion is not the most important one. I'll defer to the
community in this. I thought it worthwhile to present an alternative.

Thanks,
-Stolee