3 ms·

> Branches are Git objects That's not how I understand refs, they don't even live in the .git/objects hierarchy.

ericfrederich 9y ago
You're correct, they're just files. To create a new branch off of master you can just... cp .git/refs/heads/master .git/refs/heads/WTFFF ... no SHA-1 involved at all, no parent, history, etc.
- swsieber 9y ago
  However what they point to are git objects. And being pointed to prevent them from being garbage collected (pruned).
quadrangle 9y ago
I guess I don't understand what GitHub/GitLab does that makes branches different from Git itself (which seemed to be the claim I was replying to).
- falsedan 9y ago
  Thanks for replying, I understand your position better now. > I guess I don't understand what GitHub/GitLab does that makes branches different from Git itself [in the GP] The GP is mistaken. Their understanding of objects & refs seems different to how I've seen them refered to in the majority of git literature. For passing readers: refs (branches and tags) are just git's way of labelling a commit (which are stored as objects). GitLab/GitHub don't do anything special to implement refs: they're standard git refs. They're not different, they're 100% part of git. GitHub/GitLab do add a lot of extra refs to track things like PR/MRs. > Branches, pull requests, comments, etc... should all be Git objects of some sort. Branches can't be objects because you'd need a way to find them with a label, and then why not use the labels directly instead? PRs and comments can be stored in a repo (as refs and notes), but git doen't have a strongly-opinionated view on the exact workflow you should follow when developing, and thus isn't interested in recommending that people should always use forks & CRs.
  - quadrangle 9y ago
    Right, there's no PRs/MRs in Git itself, but branches are there, specifically in that there's nothing about the existence of or use of branches in GitHub/GitLab that needs to be brought back into Git, that stuff is already there. I recognize and accept the argument that it might be nice for Git to track merge-requests and issues (hence my link to Fossil SCM)

You're correct, they're just files. To create a new branch off of master you can just... cp .git/refs/heads/master .git/refs/heads/WTFFF ... no SHA-1 involved at all, no parent, history, etc.

swsieber 9y ago
However what they point to are git objects. And being pointed to prevent them from being garbage collected (pruned).

quadrangle 9y ago

I guess I don't understand what GitHub/GitLab does that makes branches different from Git itself (which seemed to be the claim I was replying to).

falsedan 9y ago
Thanks for replying, I understand your position better now. > I guess I don't understand what GitHub/GitLab does that makes branches different from Git itself [in the GP] The GP is mistaken. Their understanding of objects & refs seems different to how I've seen them refered to in the majority of git literature. For passing readers: refs (branches and tags) are just git's way of labelling a commit (which are stored as objects). GitLab/GitHub don't do anything special to implement refs: they're standard git refs. They're not different, they're 100% part of git. GitHub/GitLab do add a lot of extra refs to track things like PR/MRs. > Branches, pull requests, comments, etc... should all be Git objects of some sort. Branches can't be objects because you'd need a way to find them with a label, and then why not use the labels directly instead? PRs and comments can be stored in a repo (as refs and notes), but git doen't have a strongly-opinionated view on the exact workflow you should follow when developing, and thus isn't interested in recommending that people should always use forks & CRs.
- quadrangle 9y ago
  Right, there's no PRs/MRs in Git itself, but branches are there, specifically in that there's nothing about the existence of or use of branches in GitHub/GitLab that needs to be brought back into Git, that stuff is already there. I recognize and accept the argument that it might be nice for Git to track merge-requests and issues (hence my link to Fossil SCM)