4 ms·

This removes the ability for collaborating, browsing online, basically any feature of GitLab/GitHub/BitBucket. ... I think I'm in favor of this. I think of th

This removes the ability for collaborating, browsing online, basically any feature of GitLab/GitHub/BitBucket. ... I think I'm in favor of this. I think of the things that those services provide on top of Git should actually be ported or mapped to Git itself. Branches, pull requests, comments, etc... should all be Git objects of some sort.

quadrangle 9y ago
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.
mateuszf 9y ago
It could be used for storing/fetching secrets and managing access for teams of real/application users.
falsedan 9y ago
Have you seen https://github.com/google/git-appraise https://github.com/google/git-appraise
- ericfrederich 9y ago
  Cool... haven't seen that. I guess what I'm asking for is for this stuff to become standardized. Once that happens if someone wants to write a web app around it that's fine, but it'd have to be run locally where the content can be decrypted and made sense of.
pkd 9y ago
Somebody else said branches were already native to git. So are pull requests. Comments and issues are unlikely to be made native to git ever since git is developed primarily for the Linux kernel and their discussion channel is the mailing list.
danenania 9y ago
For another approach to managing API keys, secrets, and config with end-to-end encryption, check out EnvKey: https://www.envkey.com https://www.envkey.com Since it keeps secrets completely outside of git, you don't have to give up the convenience of collaboration tools by client-side encrypting the whole repository, and integration/deployment is simpler than maintaining a separate encrypted secrets repo. Here's our Show HN from last week for more detail and discussion: https://news.ycombinator.com/item?id=15330757 https://news.ycombinator.com/item?id=15330757
eridius 9y ago
GitHub pull requests actually are exposed as git objects (not the comments though, just the commits that make up the PR). If you want to see the commits in PR #515 you can just `git fetch origin pull/515/head`, or `git fetch origin pull/515/merge` to get the merge commit GitHub created when testing if your PR can be merged into the target branch.
- pkamb 9y ago
  Is this possible if the PR is coming from a fork?
  - petetnt 9y ago
    It is.
    - ThatGeoGuy 9y ago
      To expand on this, you need to add the fork as an alternate remote (as opposed to origin), and then replace "origin" in the command posted prior.
      - pkamb 9y ago
        So it's not possible from a fork, if you've only added the original repo as your single remote? Currently I add the random person's fork as a remote to inspect/modify their PR branch. Was hoping for some GitHub magic to eliminate this step.
        eridius 9y ago
        It is possible. You can specify a URL instead of a remote name for `git fetch`.
      - mook 9y ago
        I thought it was in the PR destination repository (since they are under that repository's /pull namespace). You'd need to add the alternate remote if it's a PR into a fork (as opposed to from it), no?
glibgil 9y ago
Everyone should have been collaborating through distributed code review pushed into repo branches. Take a look at how SmartGit does it

quadrangle 9y ago

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.

mateuszf 9y ago

It could be used for storing/fetching secrets and managing access for teams of real/application users.

falsedan 9y ago

Have you seen https://github.com/google/git-appraise https://github.com/google/git-appraise

ericfrederich 9y ago
Cool... haven't seen that. I guess what I'm asking for is for this stuff to become standardized. Once that happens if someone wants to write a web app around it that's fine, but it'd have to be run locally where the content can be decrypted and made sense of.

pkd 9y ago

Somebody else said branches were already native to git. So are pull requests. Comments and issues are unlikely to be made native to git ever since git is developed primarily for the Linux kernel and their discussion channel is the mailing list.

danenania 9y ago

For another approach to managing API keys, secrets, and config with end-to-end encryption, check out EnvKey: https://www.envkey.com https://www.envkey.com Since it keeps secrets completely outside of git, you don't have to give up the convenience of collaboration tools by client-side encrypting the whole repository, and integration/deployment is simpler than maintaining a separate encrypted secrets repo. Here's our Show HN from last week for more detail and discussion: https://news.ycombinator.com/item?id=15330757 https://news.ycombinator.com/item?id=15330757

eridius 9y ago

GitHub pull requests actually are exposed as git objects (not the comments though, just the commits that make up the PR). If you want to see the commits in PR #515 you can just `git fetch origin pull/515/head`, or `git fetch origin pull/515/merge` to get the merge commit GitHub created when testing if your PR can be merged into the target branch.

pkamb 9y ago
Is this possible if the PR is coming from a fork?
- petetnt 9y ago
  It is.
  - ThatGeoGuy 9y ago
    To expand on this, you need to add the fork as an alternate remote (as opposed to origin), and then replace "origin" in the command posted prior.
    - pkamb 9y ago
      So it's not possible from a fork, if you've only added the original repo as your single remote? Currently I add the random person's fork as a remote to inspect/modify their PR branch. Was hoping for some GitHub magic to eliminate this step.
      - eridius 9y ago
        It is possible. You can specify a URL instead of a remote name for `git fetch`.
    - mook 9y ago
      I thought it was in the PR destination repository (since they are under that repository's /pull namespace). You'd need to add the alternate remote if it's a PR into a fork (as opposed to from it), no?

glibgil 9y ago

Everyone should have been collaborating through distributed code review pushed into repo branches. Take a look at how SmartGit does it