On Tue, Feb 4, 2020 at 9:06 PM Jeff King <peff@xxxxxxxx> wrote: > > On Tue, Feb 04, 2020 at 07:54:12PM +0100, Han-Wen Nienhuys wrote: > > > > PS I don't know if it's set in stone yet, but if we're changing things > > > around, is it an option to put reftable-list inside the reftable > > > directory, just to keep the top-level uncluttered? > > > > I put up https://git.eclipse.org/r/c/157167/ to update the spec inside > > JGit. Please review. > > That looks quite reasonable. The one change I'd make is to put > "refs/heads/.invalid" into HEAD (instead of "refs/.invalid"). In my > experiments, existing Git is happy to write into an invalid refname via > "git update-ref HEAD". But by putting it past the non-directory "heads", > such a write would always fail. thanks, incorporated. > It's also supposed to be a requirement that HEAD only puts to > refs/heads/, though our validate_headref() does not enforce that. I > don't know if any other implementations might, though. > > I did compare earlier your "make refs/heads a file" versus "make refs/ a > file and just give it an executable bit". And I think the "refs/heads" > solution does behave slightly better in a few cases. But if I understand > correctly, just giving "refs/" an executable bit would mean we retain > compatibility with the existing JGit implementation. I hadn't looked at the JGit discovery in detail, but it looks like the currently proposed approach works with JGit. (I haven't adapted JGit for the new path setup yet.) -- 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
