Obviously this doesn't apply here, but how does that work with changes across multiple files? Even one-off changes sometimes need to touch different parts of the codebase.
The ideal workflow for me would be:
1. Clone the repo locally (not making a public fork that requires cleanup).
2. Make changes and commit them (not making a branch that requires cleanup).
3. Send the patch (or patches) for review.
4. If the patch is reviewed, it's either automatically landed or a project committer applies it and commits it. Either way, there's nothing else I have to do at this point besides deleting my local clone.
I can see how the GitHub model works for people who contribute to the same projects frequently, but there's too much stuff you have to do (forking, cloning, branching) and then un-do if you're making a drive-by change and don't want the project to clutter up your profile.
Why are you fixating on this notion of cleanup? There's no need to "clean up" your public repos.
Even if you're making complex changes, I think GitHub is much easier to work with than the classic "patch" emails.
I frequently will randomly fork a project that I'm using and submit a minor pull request when I wouldn't hunt down their source control system, clone it locally, make changes, find their preferred email/patch system, look up the commands to create a patch file, and email the patch.
GitHub is drop dead simple:
1. Click fork.
2. Edit your fork online or clone locally, committing changes.
3. Click the "pull request" button.
Just because a model is new doesn't mean it's worse.
The ideal workflow for me would be:
1. Clone the repo locally (not making a public fork that requires cleanup).
2. Make changes and commit them (not making a branch that requires cleanup).
3. Send the patch (or patches) for review.
4. If the patch is reviewed, it's either automatically landed or a project committer applies it and commits it. Either way, there's nothing else I have to do at this point besides deleting my local clone.
I can see how the GitHub model works for people who contribute to the same projects frequently, but there's too much stuff you have to do (forking, cloning, branching) and then un-do if you're making a drive-by change and don't want the project to clutter up your profile.