Why are you interested in looking at individual commits? What can you possibly learn from that that you can't get from looking at the entire diff the PR is introducing?
Does your CI test each individual commit? Afaik most of them only test the top commit. How do you know/enforce that all the inbetween commits also build/pass tests?
How do you know how many commits to revert, if you need to revert the feature? Instead of reverting 1, now you have to revert N where N is not recorded anywhere.
> Why are you interested in looking at individual commits?
Because they can explain their individual rationales, while still making the most sense to merge all together.
> What can you possibly learn from that that you can't get from looking at the entire diff the PR is introducing?
Ease of review (both before merge, and in the future when wondering why something was done a certain way). Saves me as a reviewer from having to guess which parts of the commit are meant to do what.
This, of course, means that every commit needs to be a reasonable change in itself -- fixup commits done while developing should be squashed into the original change with a local rebase (these are the "meandering" commits your parent post mentioned).
> How do you know/enforce that all the inbetween commits also build/pass tests?
I'm no CI expert, but I would hope that most systems allow this as an option.
> How do you know how many commits to revert, if you need to revert the feature? Instead of reverting 1, now you have to revert N where N is not recorded anywhere.
It's recorded in the merge, assuming you always make a merge commit.
Otherwise, since each commit is actually its own logical change, you figure it out the same way as you would figure it out in the "squash PR" model -- bisect to find it, then see if reverting it helps.
I have seen so many of these "you shouldn't do this completely normal, accepted and usual thing in $current_year because of corner case XYZ", but who is the target audience?
As a developer, I don't have the authority to decide I'm going to spend resources on making the site work without javascript. I can sneak in some extra hours, but continuously testing if the site works without it, and getting other developers to do the same is not a small task.
I did a double-take because there's two ways to read that. We have an
unusual, thin slice of humanity here on HN, a minority with
disproportionate power to impose its will upon billions while calling
others with different lifestyles "marginal", "edge cases", and so on.
I'll believe it when I see it. There are major security breaches every year, and I have never heard any company get fined or taking any responsibility. If LastPass and Okta can get away with leaking passwords, then google (or any other cloud provider) can get away with absolutely anything.
Only tangentially related, but I wonder if "indexability" is even relevant anymore. Google is getting close to useless for searching, and I would bet that all of the big tech companies are racing to write better crawlers to make sure they can suck up all the sweet free content for their next AI model, the incentive for making your site crawlable is inverted in an ironic way.
I feel it's much easier/better to concentrate on social media or sites like hn/reddit to increase your site's discoverability.
>I do not, for a second, believe most maintainers would take money in exchange for being forced to follow good best practices in coding, testing, releasing, etc
Strange, I would not expect any of that from any "enterprise". Most open source projects are much better at these than anything I have seen in enterprise.
I started with rpgmaker as well, and your comment made me so nostalgic. I remember downloading a game from rpgmaker.net that had a "custom battle system" implemented in it. They replaced the entire built in battle system with a custom implementation that used techniques like you described. I was absolutely blown away when I opened it in the editor to see how it works. It was hundreds and hundreds of "variables" (which if I remember correctly only allowed i64), and hundreds and hundreds of "switches" (which was booleans). I had no concept of stacks and heaps or function calls at that point.
I can't imagine the amount of energy it took to pull that off and maintain/debug it.
I think the skepticism towards internal testing is because Ubisoft is known to often release broken games that need to be patched up after release. I can't fault people for not trusting them to do internal evaluations if the public releases are in such state.
My take is that we are in this situation because most hiring is done by managers and/or recruiters who have very little knowledge, or are completely clueless about programming. This leads to checkmark based recruiting where the client wants tech x, candidate has tech x on his CV,
