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

Junio C Hamano <gitster@pobox.com> writes:

Thinking about this more, while I can see how using the remote-tracking branch that is pointed by refs/remotes/origin/HEAD may make sense, I see no sensible reason why mapping that to a local branch name by simply stripping refs/remotes/origin/ makes sense.

Stepping back a bit, the workflow that may be helped by being able to learn the value of "refs/remotes/origin/HEAD", in addition to @{upstream} and @{push} would be laid out like the following:

 * The project uses 'main' as its primary integration branch.  After
   you clone it, refs/remotes/origin/HEAD points at their 'main'
   (i.e., you have refs/remotes/origin/main keeping track of it),
   "git fetch" updates refs/remotes/origin/HEAD when they change
   their naming if you are using a recent enough version of Git.

 * The project uses topic based workflow.  The idea is each topic
   gets its own topic branch, e.g., 'feature', and participants join
   forces to bring it to perfection, after which 'main' merges the
   completed 'feature'.

 * You, as a participant of this project, fork your own 'feature'
   local branch from the remote-tracking branch 'origin/feature'.
   You publish the result into a separate repository of your own,
   different from where you cloned from.  If you fetch from there, a
   remote-tracking branch 'refs/remotes/publish/feature' may be
   created in your local clone as well (assuming your publishing
   repository is called 'publish').

Now, you have @{upstream} that is their 'feature' (that is kept track of with refs/remotes/origin/feature remote-tracking branch in your local clone), @{push} that is refs/remotes/publish/feature. Comparing your local progress against these two are useful to see where you are, how far you came, and how much others you see in @{upstream} may have diverged.

In addition, the overall "progress" of the project is how far @{upstream} has come relative to refs/remotes/origin/main, which is the ultimate target that you and your fellow project participants want to see @{upstream} gets merged, is a useful thing to keep track of.

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' ;-).

But step back and notice that there is no mention of local 'main' in the above layout?

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.

So, enough about refs/remotes/origin/HEAD. Back to your original idea of using init.defaultBranch.

In one of your other messages [*2*], you reported that you were having trouble with repositories without init.defaultBranch configuration variable cofigured.

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.

[References]

*1* https://lore.kernel.org/git/7b62316f-a30a-4895-808d-baa20be0f3af@app.fastmail.com/

*2* https://lore.kernel.org/git/20260131000923.70152-1-haraldnordgren@gmail.com/