This looks like a recipe for disaster when you'll free something in the return path that shouldn't be freed because it's part of the function's result, or forget to free something in a success path. Just write
result=x;
goto cleanup;
if you meant
result=x;
goto cleanup;
At least then you'll be able to follow the control flow without remembering what the magic macro does.
In your cleanup method you have to take the same care of parameters that you are putting results into as any other way you can deal with this. All it does is save you from repeating such logic at all the exit points.
No. Git is not a web-based GUI capable of managing users and permissions, facilitating the creation and management of repositories, handling pull requests, handling comments and communication, doing CI, or a variety of other tasks that sites like Codeberg and Forgejo and GitLab and GitHub do. If you don't want those things, that's fine, but that isn't an argument that git subsumes them.
People were doing that by using additional tools on top of git, not via git alone. I intentionally only listed things that git doesn't do.
There's not much point in observing "but you could have done those things with email!". We could have done them with tarballs before git existed, too, if we built sufficient additional tooling atop them. That doesn't mean we have the functionality of current forges in a federated model, yet.
That doesn't cover tracking pull requests, discussing them, closing them, making suggestions on them...
Those exist (badly and not integrated) as part of additional tools such as email, or as tasks done manually, or as part of forge software.
I don't think there's much point in splitting this hair further. I stand by the original statement that I'd love to see federated pull requests between forges, with all the capabilities people expect of a modern forge.
I think people (especially those who joined the internet after the .com bubble) underestimate the level of decentralization and federation coming with the old-school (pre web-centric mainframe-like client mentality) protocols such as email and Usenet and maybe even IRC.
Give me “email” PR process anytime. Can review on a flight. Offline. Distraction free. On my federated email server and have it work with your federated email server.
And the clients were pretty decent, at running locally. And it still works great for established projects like Linux Kernel etc.
It’s just pain to set up for a new project, compared to pushing to some forge. But not impossible. Return the intentionality of email. With powerful clients doing threading, sorting, syncing etc, locally.
I'm older than the web. I worked on projects using CVS, SVN, mercurial, git-and-email, git-with-shared-repository, and git-with-forges. I'll take forges every time, and it isn't even close. It's not a matter of not having done it the old way, it's a matter of not wanting to do it again.
I guess we might have opposite experiences. Part of which I understand - the society moved on, the modern ways are more mature and developed… but I wonder how much of that can be backported without handing over to the centralized systems again.
The advantage of old-school was partially that the user agents, were in fact user agents. Greasemonkey tried to bridge the gap a bit, but the Web does not lend itself to much user-side customization, the protocol is too low level, too generic, offering a lot of creative space to website creators, but making it harder to customize those creations to user’s wants.
I'm older than the trees, but, younger than the mountains! Email all day, all the way. Young people are very fascinated and impressed by how much more I can achieve, faster, with email, compared with their chats, web 3.0 web interfaces, and other crap.
Yes, it takes time to learn, but that is true for anything worthwhile.
What I like about git-and-email-patches is the barrier to entry.
I think it's dwm that explicitly advertises a small and elitist userbase as a feature/design goal. I feel like mailing lists as a workflow serve a similar purpose, even if unintentionally.
With the advent of AI slop as pull request I think I'm gravitating to platforms with a higher barrier to entry, not lower.
What is a forge? What is a modern forge? What is a pull request?
There is code or repository, there is a diff or patch. Everything else your labeling as pull request is unknown, not part of original design, debatable.
GitHub style pull request is not part of the original design.
What aspects and features you want to keep, and what exactly you say many others are interested in?
We don't even know what a forge is. Let alone a modern one.
The Video Rental Protection Act was passed when a video rental employee blackmailed a congressman and there was no law against it. So it's clear how to make congress write new privacy laws.
That doesn't appear to be accurate, at least from the Wikipedia article.
Robert Bork (sorry to add my personal commentary but an absolute shit stain of a human being) was nominated for the Supreme Court (which, thankfully, he always not confirmed), and a reporter went to a video rental store and asked for his rental history, which there was no law against. The published article didn't include much, as Bork hadn't rented any particularly salacious material, but there was bipartisan outrage that this had occurred.
Just goes to show how far we've fallen when there was once bipartisan outrage over accessing your Blockbuster rental history, when tech giants now have 10 times as much surveillance on you - your 1 am "shower thoughts" in your search history, all the websites you've visited, all your social media posts, and even social media posts about/including you posted by someone else, everything you've ever commented on a blog forum, your location history, etc.
And the platform will simply be banned and its creators (if identifiable) arrested. See Tornadocash. Still operating, because it's uncensorable, but the people who made it will never see daylight again.
The issue with that is that the author won't be able to edit or delete the message at any time. These are useful requirements. On Reddit I sometimes edit a message after several years, so there shouldn't be a time limit either.
reply