SourceHut may not have the pull request method of Github, may deal pretty much only in plain text, but at least it doesn't abuse your data for money and for others to use. Oh and it's accessible.

Follow

@devinprater Honestly we're always a bit scared to use email for patches because it seems like it'd mess up the hash (different committer email on the importing side? I don't know how git does that, and why should it matter who imports it). Is it easier than it seems?

@IceWolf I've not gotten any patches, but honestly I'd just accept a changed version of the file through email or something that I'd just paste in and commit that way. But I don't know. If others want to use other repos of their own, that's perfectly fine with me too. It's all honestly a mess and I'm just trying to keep it foss lol

@IceWolf @devinprater this tutorial does a great job of explaining the flow of using email with git (as a contributor)!
git-send-email.io/

@nleigh @devinprater hm... says nothing about how it handles committer email, which nobody ever talks about and we only found out existed when changing names on old commits. >,,>

@nleigh @devinprater like, it's good for the actual "how to do it" part, but says nothing on the stuff I actually want to know.

@IceWolf @nleigh What? We're supposed to avoid top posting? Well hopefully it doesn't mess with Git cause that's what I'll be doing until a good, easy-to-use email client can collapse the quoted text from bottom posting lol

git-send-email.io/#step-4

@devinprater @nleigh Honestly, I'd say if it works ignore whatever "rules" are laid out there.

@devinprater @nleigh (Honestly we just take out top and bottom posting when replying, personally. When we remember. We should change KMail's settings so it doesn't top-post by default.)

@IceWolf @devinprater
I did some testing on my own and found that when importing a patch from email with `git am`, the author email from the original commit is the one used for the applied commit, and the committer email will be from the config of whoever ran `git am`.

So in a sense, the local commit that was sent as a patch email and the one that's applied by the maintainer are different, even though their contents are the same. But from Git's perspective, they're the same, so doing a rebase won't introduce merge conflicts. Code authorship is preserved (though the author date is changed to the date of the email message by `git send-email`).

Good references are the manpages for `git format-patch`, `git send-email`, and `git am`.

@nleigh @devinprater Blorfh. So pulling commits around /is/ actually better (for the git history).

Sign in to participate in the conversation
Mastodon Glitch Edition

This is a private instance for us.