4 ms·

Branches are Git objects. Incidentally, here's a distributed VCS that includes bug tracking: https://fossil-scm.org https://fossil-scm.org

falsedan 9y ago
> 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)
rakoo 9y ago
No, branches are not git objects. An object is something that is identified by its sha1. Branches are merely files on the filesystem that point to objects.
- hasenj 9y ago
  You're thinking about branch names. The branch itself (anonymous branch?) is part of git because the commit history is a tree with branches.
  - rakoo 9y ago
    It's part of git, but is not a git object, those have a very specific definition: it's all the thing that are identified by their hash. Note that the commit history doesn't depend on branches: it's just a chain from commit to commits. The tree can exist withou any branch at all. That wouldn't be very useful, but it's still valid. Branches are merely pointers to a commit.

falsedan 9y ago

> 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)

rakoo 9y ago

No, branches are not git objects. An object is something that is identified by its sha1. Branches are merely files on the filesystem that point to objects.

hasenj 9y ago
You're thinking about branch names. The branch itself (anonymous branch?) is part of git because the commit history is a tree with branches.
- rakoo 9y ago
  It's part of git, but is not a git object, those have a very specific definition: it's all the thing that are identified by their hash. Note that the commit history doesn't depend on branches: it's just a chain from commit to commits. The tree can exist withou any branch at all. That wouldn't be very useful, but it's still valid. Branches are merely pointers to a commit.