On Tue, Feb 04, 2020 at 07:54:12PM +0100, Han-Wen Nienhuys wrote:

quoted

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.

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.

It does end up playing games with permissions, which I warned against,
but I think it might be tolerable:

  1. Unlike read vs write, there's not generally a reason users would
     need to separate read and execute.

  2. Portability-wise, POSIX permissions give us what we need, and
     non-POSIX systems tend to just say everything is executable.

So I could also live with that direction, if switching the JGit behavior
at this point is too much of a pain.

-Peff