From: Junio C Hamano Date: Thu, 29 Jan 2026 20:23:34 GMT Subject: Re: [PATCH] revisions: add @{default} shorthand for default branch Message-ID: In-Reply-To: "Harald Nordgren via GitGitGadget" writes: > From: Harald Nordgren > > Git already has shorthands like @{upstream} and @{push} to refer to > tracking branches, but there is no convenient way to refer to the > default branch of a repository (typically "main" or "master"). > > Users often want to switch to the default branch regardless of its > name, especially when working across repositories with different > default branch names. Currently they must either hardcode the branch > name or query it via configuration, which is cumbersome. > > Add a new @{default} shorthand that resolves to the default branch > as determined by init.defaultBranch (or falls back to "main" or > "master" depending on Git version). This allows users to write: > > git checkout @{default} > > instead of having to know or look up the default branch name. > > The implementation follows the same pattern as @{upstream} and @{push}, > using a new branch_get_default() function that queries the default > branch name and verifies it exists in the repository. But @{upstream} and @{push} are inherently very different from what you are adding, aren't they? Asking for topic1@{upstream} and topic2@{upstream} makes quite a lot of sense, because the meaning of @{upstream} depends on "which branch's upstream are you talking about???". But I suspect that asking for topic1@{default} and expect it would be different from topic2@{default} is nonsense, as "the default" is not per branch but is an attribute of a repository. In other words, @{default} may by itself be a nonsense query. Are you rejecting a non-empty that may appear before @{default} as an error? After cloning an upstream project, those who dislike the local branch name 'master' often rename it to something else, like $ git branch -m master main and be happy, without configuring "init.defaultbranch". After all, that configuration variable affects newly created repositories, so after renaming 'master' to 'main', it is too late anyway. In such a repository, if you say @{default}, what should happen? As 'master' branch no longer exist, even though it is the @{default}, should it error out? Does your implementation error out? Also I do not quite see how this would be useful in practice. Given that the names of local branches are under control of the local end user and not upstream projects, I would imagine that the primary branch used by a user is of per-user nature, not per repository. In other words, instead of having to do "git branch -m" after cloning, you may do "git config --global init.defaultBranch" just once and keep using the same default name. Under that condition, "can I ask what default branch name this repository uses, so that I can work on that branch" is rarely needed, if you are writing a script to use in many of your repositories, isn't it? So, I am not sure. I wouldn't mind too terribly if @{default} is rejected, but I do not imagine many people using it.