On Mon, Oct 14, 2024, at 12:16, Patrick Steinhardt wrote: > On Sun, Oct 13, 2024 at 09:57:23PM +0200, Kristoffer Haugsbakk wrote: >> […] >> This seems overly restrictive for this day and age though? No? > > There at least is no technical reason to restrict this from the ref > backend's point of view. Neither the "files" nor the "reftable" backend > enforce any restrictions except the restrictions we have in place for > any other reference: a ref is either a root ref, a pseudoref or it must > start with "refs/". > > Now the only reason why I'd say that you maybe shouldn't create weird > symrefs is that tooling isn't prepared to handle them. But that is not > sufficient reason for me to say that you mustn't create them. Thanks. This makes sense. :) ❦ I discovered/re-discovered a pitfall with the following approach: > Create a `refs/heads/<symref>` which points to a remote-tracking > branch Again, so tempting to do for me because you get a shorthand via `refs/heads`. And this is indeed fine for read-only operations (effectively). But don’t be careless and do something like commit while checked out here. Because you are checked out on an ostensibly “proper branch” (not detached HEAD) and the remote-tracking branch will move forward with a commit. So I’ve gone back to using one-level (root-level) symrefs with all-capital names. Because git-symbolic-ref(1) allows that and I haven’t gotten any weird warnings from it. (I would presumably get warnings if I then defined a ref named e.g. `refs/heads/M` if `M` was my top-level symref.)
