Re: [PATCH v2 5/5] Reftable support for git-core
- From
Han-Wen Nienhuys <hanwen@google.com>
- Date
- Jan 29, 2020, 19:50 UTC
- Message-ID
- <CAFQ2z_OgGvX3mFLeWSvEqdfxupRuHN_eFgqENaCRHHpO364_xA@mail.gmail.com>
- In-Reply-To
- <2165647.H0RpPiDeFZ@mfick-lnx>
On Wed, Jan 29, 2020 at 8:47 PM Martin Fick <mfick@codeaurora.org> wrote:
Show 14 quoted lines
> > On Wednesday, January 29, 2020 7:40:50 PM MST Han-Wen Nienhuys wrote: > > > 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?
I propose to ignore refs/ if it is read-only, and fail if it is r/w. We're not going to look over the files under refs/ . If people actively try to shoot themselves in the foot, why would we stop them?
-- Han-Wen Nienhuys - Google Munich I work 80%. Don't expect answers from me on Fridays. -- Google Germany GmbH, Erika-Mann-Strasse 33, 80636 Munich Registergericht und -nummer: Hamburg, HRB 86891 Sitz der Gesellschaft: Hamburg Geschäftsführer: Paul Manicle, Halimah DeLaine Prado