From: Harald Nordgren <haraldnordgren@gmail.com>
Date: Sat, 31 Jan 2026 20:22:32 GMT
Subject: Re: [PATCH] revisions: add @{default} shorthand for default branch
Message-ID: <20260131202232.9213-1-haraldnordgren@gmail.com>
In-Reply-To: <xmqqv7gh4mpw.fsf@gitster.g>

> 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.

> 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