@dcz
For the record:
I don't know if you've seen this. My first experience with git send-email was with this website, which explain things well enough for me that I've never had the problems you described with git send-email.
As with drafts, I've always assumed you just save your text as you would in any other text editor. In vim, I usually do something like `:w /tmp/email`, then later `:r /tmp/email`. There a probably people with mappings for this.
What you said about email patches being less than a commit, I'd say that's what `git request-pull` is for.
And for context, I use the aerc email client, which integrates nicely with all of this.
And Sourcehut too, which as you've said provides great continuity with git and email.
@dcz
I do recognise that git send-email could be improved here and there. But I think the documentation is there and sufficient enough for most people coming from most backgrounds.
@torresjrjr The problem with documentation it's that it's a crutch. Facebook doesn't need documentation, neither does Instagram, or youtube. Those are not simple products, and they all rely on submitting things the user created. Instead, most things guide the user to the right choices.
I don't see why sending patches should have documentation as the main source of knowledge.
Even worse, documentation is not going to stop me from sending something wrong by accident, like an invalid "email".
@dcz
For GUI apps, sure, good UX removes the need for documentation. But you're expecting a cli utility to be as intuitive? This is why we have man pages and wikis for even basic commands.
As for invalid emails, fair point. Though the email format is not that hard to grasp. If you're to uncomfortable with editing emails directly, perhaps you're too used to using GUI apps and HTML forms with validation. I don't want to presume too much. If you get hands on, you also have to know what you're doing, and it's generally better to aquire that skill than always using safe frontends.
@torresjrjr It's a mistake to think that I expect a CLI utility. I'm going to be rather happy when guides start pointing me to "git-send-gui". Alas, that isn't even an option as far as I know, and that's bad user experience.
I find the expression "too used" funny. I'm also used to kettles that whistle when ready. Am I "too used" to them when I am annoyed with the kettle that boils until the water is gone? "Too used to good UX" is not an excuse for bad UX.