Jonathan Nieder <jrnieder@xxxxxxxxx> 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.
