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. 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
