From: Kristoffer Haugsbakk Date: Fri, 20 Jun 2025 15:29:24 GMT Subject: Re: What’s the intended/reasonable usage patterns for symrefs? Message-ID: <74ee41f3-a9dd-4a9a-9350-33ffef7dea23@app.fastmail.com> In-Reply-To: <4e3c2840-37f3-43f8-9d8a-b4a106d8d18a@app.fastmail.com> 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/` 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/ git symbolic-ref refs/O refs/remotes/origin/ ``` 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