4 ms·

But then git isn't your source of truth anymore. GitHub still references these commits until they're garbage collected one day.

kccqzy 2y ago
My understanding is that these commits don't get garbage collected ever. After all they still need to support `gh pr checkout` so they need to store them forever as part of the GitHub repo. Sure they won't be included in `git clone` but that's kind of the point.
- keybored 2y ago
  That’s correct. They will not ge GCd. And yet that’s not usually what the problem is with having your canonical history “over there” in a proprietary webapp. But if the history is easily available on those PR refs then I guess it is (under doubt) fine.
  - skydhash 2y ago
    If you really care, you can use the API to extract the PR’s data in a local archive.
    - keybored 2y ago
      If I really care about the version control history? Yeah. Alternatively I could stick with git(1) which does all of this stuff out of the box. Instead of having to learn a superflouous (for the job) API.
      - skydhash 2y ago
        I mean the PR data. The main advantage of a forge like Github are being web browseable, working great as a backup, and the PRs (and other stuff like artifacts storage and CI). All of these have alternatives and are optional. And the API is comprehensive enough to not feel locked in.
        keybored 2y ago
        And I mean the “squashed” history. Because that’s what this subthread is about: the claim that it is available in GitHub so therefore it is fine. I want the meaningful commits to be in the Git history. Because that’s a better place than the forge.
        skydhash 2y ago
        When creating a squashed merge from the PR, it presents an interface for the commit message. You can put the information you want there. It’s not a requirement. I wrote in another thread[0] why I like this methodology, but to each project its own. [0]: https://news.ycombinator.com/item?id=41839282 https://news.ycombinator.com/item?id=41839282
        keybored 2y ago
        I know that you can write information in the commit message. That is not sufficient. Which I explained here. https://news.ycombinator.com/item?id=41839438 https://news.ycombinator.com/item?id=41839438

kccqzy 2y ago

My understanding is that these commits don't get garbage collected ever. After all they still need to support `gh pr checkout` so they need to store them forever as part of the GitHub repo. Sure they won't be included in `git clone` but that's kind of the point.

keybored 2y ago
That’s correct. They will not ge GCd. And yet that’s not usually what the problem is with having your canonical history “over there” in a proprietary webapp. But if the history is easily available on those PR refs then I guess it is (under doubt) fine.
- skydhash 2y ago
  If you really care, you can use the API to extract the PR’s data in a local archive.
  - keybored 2y ago
    If I really care about the version control history? Yeah. Alternatively I could stick with git(1) which does all of this stuff out of the box. Instead of having to learn a superflouous (for the job) API.
    - skydhash 2y ago
      I mean the PR data. The main advantage of a forge like Github are being web browseable, working great as a backup, and the PRs (and other stuff like artifacts storage and CI). All of these have alternatives and are optional. And the API is comprehensive enough to not feel locked in.
      - keybored 2y ago
        And I mean the “squashed” history. Because that’s what this subthread is about: the claim that it is available in GitHub so therefore it is fine. I want the meaningful commits to be in the Git history. Because that’s a better place than the forge.
        skydhash 2y ago
        When creating a squashed merge from the PR, it presents an interface for the commit message. You can put the information you want there. It’s not a requirement. I wrote in another thread[0] why I like this methodology, but to each project its own. [0]: https://news.ycombinator.com/item?id=41839282 https://news.ycombinator.com/item?id=41839282
        keybored 2y ago
        I know that you can write information in the commit message. That is not sufficient. Which I explained here. https://news.ycombinator.com/item?id=41839438 https://news.ycombinator.com/item?id=41839438