3 ms·
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.
by 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 agoIf you really care, you can use the API to extract the PR’s data in a local archive.
- keybored 2y agoIf 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 agoI 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 agoAnd 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 agoWhen 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 agoI 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