On Mon, Nov 4, 2024, at 11:45, Kristoffer Haugsbakk wrote: > 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`) I’ve been using some shorthands for over half a year now: ``` git symbolic-ref refs/C refs/heads/<longer branch name> git symbolic-ref refs/O refs/remotes/origin/<longer branch name> ``` E.g. I find the latter convenient for referring to some long-living branch that is also long-named. I use the remote-tracking branch directly to use as the upstream-tracking ref and to rebase on top of. I haven’t had any problems yet. -- Kristoffer Haugsbakk
