3 ms·

The most unfortunate part of all this churn is that git didn’t provide a way to ask it what a repository’s main branch is named.

by kbd 6y ago

detaro 6y ago
You can resolve to which branch <remote>/HEAD points? (as far as I understand, local repos don't have a concept of a "main branch", it's only a thing concern remotes and the default branch checked out when cloning them?)
- kbd 6y ago
  > as far as I understand, local repos don't have a concept of a "main branch" $ git init Initialized empty Git repository in... $ git symbolic-ref --short HEAD main $ git switch --create feature-branch Switched to a new branch 'feature-branch' $ git switch ??? > You can resolve to which branch <remote>/HEAD points? Correct, this is the best way I've found. I have this as a git-alias: main-branch = !basename $(git symbolic-ref refs/remotes/origin/HEAD) But it doesn't help for local repositories that don't have a remote. And it's ironic to need to use "origin" for that, which is itself a "master/main"-like default remote name.
  - detaro 6y ago
    that's what I mean: "main" is just the automatically created branch so that there is a branch for HEAD to point to in an empty repo. It's not special in any functional way locally. I.e. if I create "develop" and delete "main", locally nothing in git itself will ever miss "main" or needs to be told that "develop" is the primary branch, because that's not a concept locally (afaik). It knows the current branch (HEAD), that's it. So wanting to look it up locally doesn't make sense from gits perspective, although maybe the ability to tag a branch as such would be useful for some tooling, but it would in a way introduce the concept to git, not expose something it hides now.
- kevincox 6y ago
  This usually works but not all git remotes have a `/HEAD` ref. I think GitHub always does though.
rualca 6y ago
This is not unfortunate at all. This is something that only has an impact when you create a brand new git repo,which is relatively rare. When that happened, you could just rename the original master branch. Nevertheless, git added support for this option less than a year ago. https://github.blog/2020-07-27-highlights-from-git-2-28/#introducing-init-defaultbranch https://github.blog/2020-07-27-highlights-from-git-2-28/#int...
- kbd 6y ago
  > This is something that only has an impact when you create a brand new git repo,which is relatively rare. What a strange thing to claim, when both this thread and the original post talk about things that need to update based on the change, such as CI/CD scripts, git aliases, and so on. > Nevertheless, git added support for this option less than a year ago. Yes, I'm just saying it's strange that git added support to customize the name, but then didn't add a way to ask it what it's configured to, given that things will depend on knowing what that name is.
  - rualca 6y ago
    > What a strange thing to claim, when both this thread and the original post talk about things that need to update based on the change, such as CI/CD scripts, git aliases, and so on. I believe I've said something that's easy to understand, at least without bad faith. Git end users create repos only rarely, but creating preconfigured Git repos is gitlab's business. This discussion is about gitlab's announcement. Do you have a hard time understanding any of this? > Yes, I'm just saying it's strange that git added support to customize the name, but then didn't add a way to ask it what it's configured to, given that things will depend on knowing what that name is. It's called software development best practices, particularly adding changes in a backward-compatible way so that not to change the expected behavior.
    - Shish2k 6y ago
      > I believe I've said something that's easy to understand, at least without bad faith. I’m pretty sure I understand what you’re saying - "this change only affects creation of new repos”? The responder isn’t missing your point, they’re disagreeing with it - they're pointing out that anybody who needs to work with a repo now needs to explicitly configure the name of the canonical branch, where previously they could safely assume the default was “master”; ergo it affects anybody who uses a repo for as long as it exists, not just the repo creator and not just at repo creation time. > adding changes in a backward-compatible way so that not to change the expected behavior The expected behaviour until recently was that “git checkout master” would take you to the canonical source branch - this behaviour has changed, in a backward-incompatible way (any code which worked in the past by using that command now needs to be changed)
deleted 6y ago
[deleted]

The most unfortunate part of all this churn is that git didn’t provide a way to ask it what a repository’s main branch is named.

by kbd 6y ago

The most unfortunate part of all this churn is that git didn’t provide a way to ask it what a repository’s main branch is named.

detaro 6y ago

You can resolve to which branch <remote>/HEAD points? (as far as I understand, local repos don't have a concept of a "main branch", it's only a thing concern remotes and the default branch checked out when cloning them?)

kbd 6y ago
> as far as I understand, local repos don't have a concept of a "main branch" $ git init Initialized empty Git repository in... $ git symbolic-ref --short HEAD main $ git switch --create feature-branch Switched to a new branch 'feature-branch' $ git switch ??? > You can resolve to which branch <remote>/HEAD points? Correct, this is the best way I've found. I have this as a git-alias: main-branch = !basename $(git symbolic-ref refs/remotes/origin/HEAD) But it doesn't help for local repositories that don't have a remote. And it's ironic to need to use "origin" for that, which is itself a "master/main"-like default remote name.
- detaro 6y ago
  that's what I mean: "main" is just the automatically created branch so that there is a branch for HEAD to point to in an empty repo. It's not special in any functional way locally. I.e. if I create "develop" and delete "main", locally nothing in git itself will ever miss "main" or needs to be told that "develop" is the primary branch, because that's not a concept locally (afaik). It knows the current branch (HEAD), that's it. So wanting to look it up locally doesn't make sense from gits perspective, although maybe the ability to tag a branch as such would be useful for some tooling, but it would in a way introduce the concept to git, not expose something it hides now.
kevincox 6y ago
This usually works but not all git remotes have a `/HEAD` ref. I think GitHub always does though.

rualca 6y ago

This is not unfortunate at all. This is something that only has an impact when you create a brand new git repo,which is relatively rare. When that happened, you could just rename the original master branch. Nevertheless, git added support for this option less than a year ago. https://github.blog/2020-07-27-highlights-from-git-2-28/#introducing-init-defaultbranch https://github.blog/2020-07-27-highlights-from-git-2-28/#int...

kbd 6y ago
> This is something that only has an impact when you create a brand new git repo,which is relatively rare. What a strange thing to claim, when both this thread and the original post talk about things that need to update based on the change, such as CI/CD scripts, git aliases, and so on. > Nevertheless, git added support for this option less than a year ago. Yes, I'm just saying it's strange that git added support to customize the name, but then didn't add a way to ask it what it's configured to, given that things will depend on knowing what that name is.
- rualca 6y ago
  > What a strange thing to claim, when both this thread and the original post talk about things that need to update based on the change, such as CI/CD scripts, git aliases, and so on. I believe I've said something that's easy to understand, at least without bad faith. Git end users create repos only rarely, but creating preconfigured Git repos is gitlab's business. This discussion is about gitlab's announcement. Do you have a hard time understanding any of this? > Yes, I'm just saying it's strange that git added support to customize the name, but then didn't add a way to ask it what it's configured to, given that things will depend on knowing what that name is. It's called software development best practices, particularly adding changes in a backward-compatible way so that not to change the expected behavior.
  - Shish2k 6y ago
    > I believe I've said something that's easy to understand, at least without bad faith. I’m pretty sure I understand what you’re saying - "this change only affects creation of new repos”? The responder isn’t missing your point, they’re disagreeing with it - they're pointing out that anybody who needs to work with a repo now needs to explicitly configure the name of the canonical branch, where previously they could safely assume the default was “master”; ergo it affects anybody who uses a repo for as long as it exists, not just the repo creator and not just at repo creation time. > adding changes in a backward-compatible way so that not to change the expected behavior The expected behaviour until recently was that “git checkout master” would take you to the canonical source branch - this behaviour has changed, in a backward-incompatible way (any code which worked in the past by using that command now needs to be changed)

deleted 6y ago

[deleted]