[kccqzy]

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]

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]

If you really care, you can use the API to extract the PR’s data in a local archive.

[keybored]

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]

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]

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]

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