On Mon, Feb 03, 2020 at 05:39:55PM +0100, Han-Wen Nienhuys wrote: > OK, so permissions are out. How about: > > HEAD - convincing enough for old versions to accept > refs/ - a standard rwx directory > reftable/ - a normal directory > reftable-list - the list of tables > reads/heads - a file containing "this repo uses reftables. Upgrade > to git vXYZ" > > this would prevent people from erroneously creating normal branches. That seems reasonable. They could still write "refs/tags/foo", etc, but presumably branches would be more common. Trying to write to any ref there (including HEAD, assuming it has a dummy value in refs/heads/) would yield something like: fatal: cannot lock ref 'HEAD': unable to create lock file .git/refs/heads/master.lock; non-directory in the way Unfortunately reading with an old version would quietly return "no such ref", at least with old versions of Git (but those maybe aren't as interesting as alternate implementations, since old versions of Git would also complain about the extensions marked in the config). Iterating with "for-each-ref" would say something like: $ git for-each-ref warning: ignoring broken ref refs/heads $ echo $? 0 which is so-so. Replacing "refs/" with a file with an executable bit (which is still playing with permissions, but I think in a little bit less exotic way) behaves similarly, except that for-each-ref does not even produce a warning. :-/ I dunno. I wish the failure mode were a little more complete. OTOH, I'm really not that worried about it. The config repo-version stuff is _supposed_ to be the definitive word on whether Git is willing to open up a repository. So this is really belt-and-suspenders on top of that. -Peff 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?
