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

"Harald Nordgren via GitGitGadget" [off-list ref] writes:

From: Harald Nordgren <redacted>

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, <branch>@{default} may by itself be a nonsense
query.  Are you rejecting a non-empty <branch> 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 <name>@{default}
is rejected, but I do not imagine many people using it.

Thanks for your comments!

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, <branch>@{default} may by itself be a nonsense
query.  Are you rejecting a non-empty <branch> that may appear
before @{default} as an error?

I will update the code to treat 'new-branch@{default}' as nonsense, it's
not a case I thought about, and would never use 😅

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

I have never heard about anyone doing that. Isn't it more expected that
people keep whatever branch is on the remote? But regardless, I hope
there is a way to still make @{default} map to whatever your renamed your
default branch to.

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.

My ratio on cloning other people's repo vs. create new repos is likely
999/1, so I'm given the default names that maintainer chose. I have
default branches called 'master', 'main' and 'develop'.

Yes it's possible to rename, but what this feature does is open up the
convenience of not having to bother with that.

I have this script that I run many times a day. However it doesn't work
when remote is not called 'origin', so I have another version for
'upstream', etc:

    git checkout $(git symbolic-ref refs/remotes/origin/HEAD | sed 's@^refs/remotes/origin/@@')

That's uneccessary overhead, that could now be replaced with:

    git checkout @{default}


Harald

I realize now when looping over all repos on my machine that quite a few of
them error out with

   error: pathspec '@{default}' did not match any file(s) known to git

I would expect all of them to have a default branch set. Maybe this is a
showstopper 🤔


Harald