Re: [PATCH v2 5/5] Reftable support for git-core
- From
- Martin Fick <mfick@codeaurora.org>
- Date
- Jan 29, 2020, 19:47 UTC
- Message-ID
- <2165647.H0RpPiDeFZ@mfick-lnx>
- In-Reply-To
- <CAFQ2z_NkU6ekZkMqZpcFSEr8M3kfw0tiVCB2doHp3QTZtQ8UNg@mail.gmail.com>
On Wednesday, January 29, 2020 7:40:50 PM MST Han-Wen Nienhuys wrote:
Show 15 quoted lines
> On Wed, Jan 29, 2020 at 5:49 PM Martin Fick <mfick@codeaurora.org> wrote: > > > If you're actually doing the correct locking and packed-refs read (which > > > "real" implementations like libgit2 do) then no, I don't think that's > > > dangerous. And I think libgit2 properly complains when it sees a > > > repositoryformatversion above 0. I don't know offhand about JGit, or any > > > of the lesser-used ones like dulwich or go-git. > > > > Today, some of these sound like shortcuts that are very likely taken quite > > a bit by cleanup and other maintenance scripts (not necessarily formal > > git tools), and the impact of these shortcuts is likely low with the > > current model. However, I suspect these tools/scripts could be seriously > > disruptive if we leave the refs dir around when using reftable, > > Maybe we can leave the refs dir, but have no heads/ directory inside, > and make the whole thing read-only?
That might be a good enough safety. I guess the next question would be, would it be OK for reftable to ignore and entries under the refs/ dir if they happen to appear there somehow?
-Martin
-- The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation