Re: [PATCH] revisions: add @{default} shorthand for default branch

[Phillip Wood <phillip.wood123@gmail.com>]

On 31/01/2026 20:22, Harald Nordgren wrote:
>> So in that sense, I do understand why somebody may find it useful if
>> there is a handy short-hand for refs/remotes/origin/main (or
>> whichever branch is pointed at by refs/remotes/origin/HEAD) in the
>> above picture.  And refs/remotes/origin/HEAD already does have a
>> handy short-hand, which is 'origin' ;-).
> 
> 'git checkout origin' doesn't work without resulting in a detached head.

That's expected because it refers to a remote tracking branch. Please 
correct me if I'm wrong but I think maybe what you're asking for is a 
shorthand for the branch "$b" where

	git push origin $b

would update the remote tracking branch pointed to by "origin/HEAD". 
I've not really thought this through but if that is what you want maybe 
we could add "@{local}" to give that branch. Then, with the default 
refspecs and with "origin/HEAD" pointing to "origin/master", 
"origin@{local}" would be "refs/heads/master". If you created a feature 
branch with

	git checkout -b feature origin

and you wanted to merge it into the local branch corresponding to the 
default branch on its upstream remote you could do

	git checkout feature@{upstream}@{local}
	git merge feature

I don't really understand what you're trying to achieve and I'm not sure 
if the suggestion above is a good idea but it might help understand what 
it is you're trying to do. Below you say you don't work directly on the 
main branch but then later on you're then creating a release from it. Is 
"main" just a mirror of "origin/main" or are you merging local work into 
it as well?

Thanks

Phillip

>> As Kristoffer said in another message [*1*], I would too expect that
>> people would not work on their 'main' (or have their 'main' track
>> the upstream's 'main').  So the utility of the piping to sed we saw
>> above is dubious, unless we are talking about quite different
>> workflow, but I do not think of what that other workflow would look
>> like that makes a neutral synonym for 'main' useful.
> 
> I don't work directly on the main branch.
> 
> However it serves and the only starting point for creating any new feature
> branches. This is the command I use, and would be nice if it could be
> simplified:
> 
>      git fetch --all
>      git checkout $(git remote | rg '^(origin|upstream)$' | tail -n1)/HEAD -b new_branch
> 
> The main branch is used in my work frontend project for the app release
> command, so there I do
> 
>      git checkout $(git symbolic-ref refs/remotes/origin/HEAD | sed 's@^refs/remotes/origin/@@')
>      yarn release
> 
> I think me as a non-hardcore Git maintainer spend more time in different
> repos than you two do, so maybe the pain of switching between systems is
> more pronounced. That's my motivation for unifying stuff.
> 
> Just for reference, iterating all forked open-source repos on my machine
> these are the different upstream names I work with:
> 
>      99designs/gqlgen
>      refs/remotes/upstream/master
> 
>      amplitude/experiment-react-native-client
>      refs/remotes/upstream/main
> 
>      Antonboom/testifylint
>      refs/remotes/upstream/master
> 
>      cli/cli
>      refs/remotes/upstream/trunk
> 
>      datastax/python-driver
>      refs/remotes/origin/master
> 
>      dependabot/dependabot-core
>      refs/remotes/origin/main
> 
>      derailed/k9s
>      refs/remotes/origin/master
> 
>      elastic/go-elasticsearch
>      refs/remotes/upstream/main
> 
>      git/git
>      refs/remotes/upstream/master
> 
>      gitgitgadget/gitgitgadget
>      refs/remotes/upstream/main
> 
>      github-linguist/linguist
>      refs/remotes/origin/main
> 
>      go-redis/redis_rate
>      refs/remotes/origin/v10
> 
>      golang-migrate/migrate
>      refs/remotes/upstream/master
> 
>      golang/go
>      refs/remotes/origin/master
> 
>      golangci/golangci-lint-action
>      refs/remotes/upstream/main
> 
>      gradle/gradle
>      refs/remotes/origin/master
> 
>      Homebrew/brew
>      refs/remotes/origin/main
> 
>      jwalton/gh-docker-logs
>      refs/remotes/upstream/master
> 
>      Khan/genqlient
>      refs/remotes/upstream/main
> 
>      kubernetes-sigs/controller-tools
>      refs/remotes/origin/main
> 
>      kubernetes/kompose
>      refs/remotes/origin/main
> 
>      kubernetes/kubernetes
>      refs/remotes/origin/master
> 
>      ldez/usetesting
>      refs/remotes/origin/main
> 
>      liushuangls/go-anthropic
>      refs/remotes/upstream/main
> 
>      matryer/moq
>      refs/remotes/upstream/main
> 
>      mhemmings/revenuecat
>      refs/remotes/origin/master
> 
>      ohmyzsh/ohmyzsh
>      refs/remotes/upstream/master
> 
>      prettier/prettier
>      refs/remotes/origin/main
> 
>      RevenueCat/docs
>      refs/remotes/upstream/main
> 
>      RevenueCat/purchases-ios
>      refs/remotes/origin/main
> 
>      RevenueCat/react-native-purchases
>      refs/remotes/origin/main
> 
>      sashabaranov/go-openai
>      refs/remotes/upstream/master
> 
>      stretchr/testify
>      refs/remotes/origin/master
> 
>      vektah/gqlparser
>      refs/remotes/upstream/master
> 
> 
>> Doesn't repo_default_branch_name() do the right thing without being
>> noisy at all even in a repository without that configured, as the
>> function will fall back to the built-in default?  While I do not
>> think of a workflow in which a handy access to the value the
>> function gives would be so useful that it deserves a short-hand, it
>> would be a reasonable candidate of what to be called "@{default}",
>> if it proves useful, I would think.
> 
> I'll play around with this a bit and see how it works. Thanks for the tip!
> 
> 
> Harald
>