[fxtentacle]

I thought the article was quite clear:

Signing a commit creates an expectation that you approved of the code. And it's permanent, so easy to screw up with lasting effects.

But a signed commit really just means that whoever created it could run a CLI tool on your computer.

That means the expectation of quality created by signing is misleading.

[nusl]

If you’re equating signing a commit to traditional code approval you fundamentally misunderstand the point of signing a commit or what a signature is in cryptography. You “approve” the code by authoring the commit but the signature is a verifiable stamp to say it was you, not the approval itself.

In that case you probably need training or self-education. If your company tells you to sign commits but doesn’t tell you why, that’s on them. If you sign commits and don’t take the time to understand why, that’s on you.

Also, if you think quality comes from approval or signing a commit you’re also not understanding code quality because there is a huge amount of terrible approved code out there.

Just because someone doesn’t understand something doesn’t mean it’s bad or shouldn’t happen. It means that there’s possibly a gap that’s causing the misunderstanding that should be addressed, or the wording changed to be less ambiguous.

[fragmede]

> But a signed commit really just means that whoever created it could run a CLI tool on your computer.

"just" is doing a lot of work there. Someone running their code on your computer is a big deal! Hopefully it's benign and sandboxed, in the case of webpages and JavaScript, but if an attacker is running code, be it a cli tool or otherwise, on your computer, you should be really worried. If somebody is signing git commits under your name on your computer, they could just as easily wait until you login to your bank's website and steal your money.