Imagine a feature in git, where when you merge, you get a single new commit on the main branch like you want, where the message could describe the changes in summary, like you want. But also: the commit contains a reference to the source branch so you can easily find it back, break it down, bisect into it, all without having to leave git or rely on data stored at 3d parties. That would be pretty neat! It's like, the best of both worlds, but all inside git!
Well. That's what a merge commit is.
Your approach is nearly identical to creating a merge commit, except the pointer to the second parent (the "original branch") is indirectly recorded via the PR link, instead of directly inside git.
If you create merge commits, then you have your "clean main branch" (via git log --first-parent), as well as the extended history with all the source commits (via git log). And as a bonus, merge commits are supported by every git host, and they work the same in all of them.
I think the whole "squash merge vs merge commit" discussions would be a lot less prevalent if --first-parent would be how git and git hosts displayed commit histories by default. :(
Let's say the attack becomes hugely succesful and the worm spreads to thousands of devices. GitHub/NPM could just revoke all compromised tokens (assuming they have a way to query) stopping the worm in its tracks. But because of the Dead Mans Switch, they'd know that in doing so, they'd be bricking thousands of their user's devices. So it effectively moves the responsibility to revoke compromised tokens from a central authority that could do it en-masse, to each individual who got compromised, greatly improving the worm's chances of survival.
> I wouldn't even be against requiring a professional certification organization for developers before they're allowed to publish software to the masses
Is Google that organization? Because they themselves have decided that they are. I think what people are worried about is that Google is positioning itself to be the judge, jury, and executioner within such a licensing framework, not necessarily the licensing itself.
> This is just to address malicious code.
Yes, and if Google had shown that it's capable of identifying and rejecting malicious code distributed via its own app store, then maybe their proposed expansion of that security program to the entirety of the Android app ecosystem would carry some weight. But as it stands, their Play Store is full of user-hostile and often malicious apps[1].
> If you publish software for a private group of people, there should be no restrictions. If you're publishing it on a platform that would expose your software to billions of people, get a license after id verification
But that's exactly the opposite of what Google is doing, here, and why people are mad. Google isn't adding a new policy to their app distribution platform (the play store that grants exposure to billions of users), but rather they are forcing ID verification on any form of app distribution: If you want any regular user to be able to install your code, no matter how small the audience, you'll need to first give your identity to Google, and obtain a (paid[1]?) license. So the restrictions do apply to "a private group of people" too.
The crux, and what has people up in arms I think, is the overreach of Google's peoposed licensing policy to cover not only their own app distribution ecosystem, but all others targeting Android.
Many technical users of Android consider it to be a general purpose computing platform, and they want to retain the freedom to install and run whatever software they trust.
Google should focus their supposed concerns about regular user's safety on the user-hostile apps that they allow to exist in their own app store, rather than grasping for broader control that they'll "probably use at some point but only for good things like user security".
Well. That's what a merge commit is.
Your approach is nearly identical to creating a merge commit, except the pointer to the second parent (the "original branch") is indirectly recorded via the PR link, instead of directly inside git.
If you create merge commits, then you have your "clean main branch" (via git log --first-parent), as well as the extended history with all the source commits (via git log). And as a bonus, merge commits are supported by every git host, and they work the same in all of them.
I think the whole "squash merge vs merge commit" discussions would be a lot less prevalent if --first-parent would be how git and git hosts displayed commit histories by default. :(