Re: [PATCH 00/28] Use main as default branch name

Jonathan Nieder [off-list ref] writes:

That said, if I put myself in the shoes of such a script author for a
moment, I'm likely to be irritated.  What started as a static string
now becomes something dynamic.  If I put myself in the shoes of
someone who has *inherited* a script (a testsuite, maybe), I'm likely
to be even more irritated.

It is conceptually really nice to say that we do not use words like
'master' and 'main' that are 'meaningless' in the context of
thinking about the workflow used for the project and instead pick
the word the end user chose to call (some aspect of) the project
(i.e. the name of the directory to host its working tree).  It
however is much harder to defend the design in real life because it
can lead to the irritations you mention.

Are there things we can do to make a script author's life easier?

It largely depends on what "specialness" of 'master' branch the
script is interested in, isn't it?

Today if I want to look up a remote repository's default branch,
the best I can do is

	git ls-remote --symref origin HEAD

The output is not as easy to parse as I'd like:...

In a sense, these follower repositories are easier to work with.

You have refs/remotes/origin/HEAD that indicates what the owner of
the local repository considers of the most significance; it is
initialized to match what the remote had pointed with its HEAD when
the repository was cloned, but the local user can repoint it when
the local interest diverge from that of the remote's.  And you do
not need to talk over the network with ls-remote to find that
out (actually asking ls-remote may actively be wrong after the
local user repointed it); you only need to ask 'git symbolic-ref'
which is totally local.