On Sun, Feb 25, 2024 at 09:16:49AM -0800, Junio C Hamano wrote: > Patrick Steinhardt <ps@xxxxxx> writes: > > > That's ultimately the reason why I don't want HEAD to look like a proper > > ref. But doing the "refs/heads/.invalid" workaround shouldn't be too bad, > > I guess. > > Isn't the reason why reftable backend initializes refs/heads to be a > regular file exactly because we want to reject an attempt to create > such a file on the filesystem, though? Yeah, "refs/heads" being a file is also part of this mechanism. But that wouldn't help a client that e.g. uses git-symbolic-ref(1) while assuming the old "files" backend, because they would now get a plausible value of whatever value we have in there if we were to initialize it e.g. with "refs/heads/main". That's why we have both mechanisms -- it's a bit like defense in depth. One could go even further and make "HEAD" contain complete garbage, only, so that anybody who was trying to read it would fail immediately. Patrick
Attachment:
signature.asc
Description: PGP signature
