Hostile forges will help though, unless the forge gets big enough.
Scrapers (SEO bots included) tend to only have a handful of "corner cases" built for navigating sites - if your code forge is actively trying to prevent scraping it could help prevent quite a lot.
Your choices remain important, even if it's not foolproof.
An account would be tied to a users table record as well as a profile, activity log, etc. Git is decentralized but source forges on average are not. I can make a commit to your code if you share the repo, but committing that code under my git user/email doesnt create an account on the source forge.
> It’s probably the core reason developers choose GitHub as their main git forge. I get it. It does have it’s advantages of giving a better experience for reviewing a set of changes. Initially. But what if I told you there was a time when submitting email-based patches was the standard for version control?
The author explains well how you can bear with patches, but not why patches were chosen in the first place. What advantages do they have over PR? I see none, and I won't lose my precious time working-around an inferior process to Github's already subpar PR one.
One very crucial point that no forge (IIRC) supports that the article missed (or I accidentially skipped it) is that email supports tree-style discussion! That is a HUGE benefit IMHO, especially for patchsets, but also for "issue" discussion!
Not a single open source license will protect you. (And it won't help even if they add an exclusion clause for AI).
Scrapers (SEO bots included) tend to only have a handful of "corner cases" built for navigating sites - if your code forge is actively trying to prevent scraping it could help prevent quite a lot.
Your choices remain important, even if it's not foolproof.
I didn't quite get why that is. Isn't an account effectively just an email, with an additional password?
> It’s probably the core reason developers choose GitHub as their main git forge. I get it. It does have it’s advantages of giving a better experience for reviewing a set of changes. Initially. But what if I told you there was a time when submitting email-based patches was the standard for version control?
The author explains well how you can bear with patches, but not why patches were chosen in the first place. What advantages do they have over PR? I see none, and I won't lose my precious time working-around an inferior process to Github's already subpar PR one.