On Wed, Oct 16, 2024, at 19:23, Kristoffer Haugsbakk wrote: > On Mon, Oct 14, 2024, at 12:16, Patrick Steinhardt wrote: > > […] > > 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.) Another newbie mistake. I used e.g. `H` (root level). But then I was in a worktree and discovered that these root-level refs are per worktree. But this works across worktress: ``` git symbolic-ref refs/H HEAD ``` (Or `refs/h`) -- Kristoffer Haugsbakk
