3 ms·

>"GitHub" is essentially just "git" on some someone else's computer with a bunch of extra features. The comment below you answered my question : PR/Issues are

>"GitHub" is essentially just "git" on some someone else's computer with a bunch of extra features. The comment below you answered my question : PR/Issues are native to github.

bogomipz 9y ago
I'm not sure what you mean by "PR/Issues are native to github", there are other choices for code review for self-hosted git: https://www.gerritcodereview.com/ https://www.gerritcodereview.com/ Incidentally Gerrit predates github.
- CydeWeys 9y ago
  "GitHub PRs/issues are native to GitHub". If you switch to Gerrit, the code commits themselves follow, but the PRs and issues don't. They're only on GitHub.
- 0x0 9y ago
  I wouldn't point to gerrit as an example of self-hosting git. Gerrit's "patchsets" and "change-id"s concepts, as well as the weirdo remote push refs, really turns the git experience into something... very different. It's very far from both how "normal" git commits and tracking branches workflow work, and from github/gitlab/bitbucket's pull-request/merge-request style.
  - bogomipz 9y ago
    How is it not a an "example of self-hosting git" when it's built on top of git? I understand from your comment that it's not your preference but that doesn't mean its not a self hosted git solution.
    - 0x0 9y ago
      Because the gerrit workflow is extremely different from all other common git workflows (which is to say, you build a set of commits in your own branch or fork and ask the maintainer to pull it). Gerrit actively encourages you to rebase and rewrite (and lose) your development history in the pursuit of a "perfect" one-hot non-merge history patchset, which actively loses information about the context of where your changes where applied. The problem with submitting a rebased branch is that while there are no apparent merge conflict and your changes appear to have been developed on the tip of master, your changes may actually have been developed on a much older version of master. Builds may appear to compile fine but they might not make sense - when you discard and rebase the context of commits, you lose important information.

>"GitHub" is essentially just "git" on some someone else's computer with a bunch of extra features. The comment below you answered my question : PR/Issues are native to github.

bogomipz 9y ago

I'm not sure what you mean by "PR/Issues are native to github", there are other choices for code review for self-hosted git: https://www.gerritcodereview.com/ https://www.gerritcodereview.com/ Incidentally Gerrit predates github.

CydeWeys 9y ago
"GitHub PRs/issues are native to GitHub". If you switch to Gerrit, the code commits themselves follow, but the PRs and issues don't. They're only on GitHub.
0x0 9y ago
I wouldn't point to gerrit as an example of self-hosting git. Gerrit's "patchsets" and "change-id"s concepts, as well as the weirdo remote push refs, really turns the git experience into something... very different. It's very far from both how "normal" git commits and tracking branches workflow work, and from github/gitlab/bitbucket's pull-request/merge-request style.
- bogomipz 9y ago
  How is it not a an "example of self-hosting git" when it's built on top of git? I understand from your comment that it's not your preference but that doesn't mean its not a self hosted git solution.
  - 0x0 9y ago
    Because the gerrit workflow is extremely different from all other common git workflows (which is to say, you build a set of commits in your own branch or fork and ask the maintainer to pull it). Gerrit actively encourages you to rebase and rewrite (and lose) your development history in the pursuit of a "perfect" one-hot non-merge history patchset, which actively loses information about the context of where your changes where applied. The problem with submitting a rebased branch is that while there are no apparent merge conflict and your changes appear to have been developed on the tip of master, your changes may actually have been developed on a much older version of master. Builds may appear to compile fine but they might not make sense - when you discard and rebase the context of commits, you lose important information.