19 ms·

Email and Git = <3

289 points by pmarin 3y ago

0xbadcafebee 3y ago
It is way faster and easier for me to just open up my email client, attach a patch, and send it.
vimsee 3y ago
Not related to Git + git-email. I just want to say that I love the way this website is structured. Also, it renders fast.
- mkmk 3y ago
  It’s miserable on mobile. Confusing unlabeled next button at the bottom of the page, plus an orange next button that seems to do the same thing but sometimes randomly overlaps the content. Why not have all the content on one page?
  - dsaravel 3y ago
    I did not test on mobile and maybe it should have all the steps in single page for that aspect ratio (easier to simply scroll). However, for desktop, it was such a beautiful way to guide the reader each step of the way. It was really well done.
keepamovin 3y ago
I love this. This is how it was done back in the days of usenet. People would email patches to the linux kernel. Hackers, working alone, late at night, strange times, strange places. Cultivating their work and skills and then ... shoot ... sending an email! Their contribution. So cool! Maybe we should go back to this. Get rid of the whole github thing. Every group their own little mailing list. Laboring in private!
- dewey 3y ago
  > Hackers, working alone, late at night, strange times, strange places. Cultivating their work and skills and then ... shoot ... sending an email! Very poetic, but also not much different to the current state. Just clicking to open a PR instead of sending an email attachment.
  - nkjoep 3y ago
    correct. Opening a PR triggers an email. No difference at all.
  - keepamovin 3y ago
    :) Thank you! I guess I prefer text. And deeply there's a difference between staying in text, and moving to GUI. The medium is the message^0, and even if the process is "the same", everything becomes different because you're no longer within the text world. 0: https://en.wikipedia.org/wiki/The_medium_is_the_message https://en.wikipedia.org/wiki/The_medium_is_the_message
    - dewey 3y ago
      I know it's not the same, but that's also why I prefer GitLab's "--push-option=merge_request.create" which creates a PR from the CLI without needing me to open the website and clicking a button. I'm still annoyed daily that this doesn't exist for GitHub.
      - pjm331 3y ago
        GitHub has a CLI https://cli.github.com/manual/gh_pr_create https://cli.github.com/manual/gh_pr_create
        dewey 3y ago
        Yes, but the advantage with the "push options" is that I can put it in my .gitconfig and it just works automatically when I do a git push without using some proprietary platform's cli.
      - 3y ago
- yankput 3y ago
  sr.ht does that I don’t find it very user friendly (well, at all), but if you want a git forge that does that, you can use it.
  - junon 3y ago
    This is my experience as well. I love the hacker culture associated with it and it's very fun to use e.g. Mutt, sr.ht, and git-send-email together, but it's anything but efficient and straightforward. I ultimately moved away from sr.ht for that reason.
    - ploum 3y ago
      Some, like myself, find the mouse really painful to use and hate graphical interfaces when you have to randomly click to find something (while you can read a man page, grep through it and then automatize the process in custom scripts). But it is not only about efficiency. It is about control and centralisation. Git-send-mail works everywhere there’s an email. It allows people to use the tool they prefer. It allows them to build custom tools. It doesn’t make people dependent from a forge (you are a simple "git remote set-url" away from using a new forge). Github forces everybody to use the same graphical interface which requires tons of JS and lot of CPU. Github forces you to accept all their changes. Github forces you to be a slave of Microsoft and contribute all your code to their IA training set. Github forces you to be notificed of stuff you don’t care. The "Hacker culture" is first and foremost about personal freedom. And if you believe the tool are not efficient, as a true hacker, you will built others (but, spoiler, most of the time, when you become proficient enough to build you own tools, you realize how efficient the existing ones are). Hacking is like walking. You look at walkers and you think it looks tiring to walk. So you go to the parking lot. You start your car. You go through the gate and give your driver license to the cop controlling you. You then go to the gas station. You pay with you credit card. There’s an accident in front of you, you are stuck in the traffic. You take your Google controlled GPS and ask for another itinerary. You drive. You wait at a red light, looking at your phone. A notification to pay the insurance of the car. Another one to pay for the leasing of the car itself. A light blink on the dashboard: you need to add oil and do the annual checkup of the car. You drive, you are a bit stressed and go too fast. You see a flash. Shit! Will I get a ticket? I was not that fast? You arrive at destination. There’s no room left in the parking. You start to drive around, hoping for a spot. There! You get it. It is bit small. You hope that nobody will scratch your car. For whatever reason, you learned that cars can’t be scratched so you are very careful. You get out of the car and walk a bit to the destination. Then you see them… The walkers. They went here by foot, through a path in the forest. They are smiling, even if they was some light rain. And you ask them: "Why don’t you guys get a car? Seriously? Walking is hard and inefficient. I can’t walk myself for than 1km before getting my legs sore."
- terminalcommand 3y ago
  Many oss projects still do this, don't they. I am subscribed to debian and python mail lists. Debian's lists are highly active.
  - rightbyte 3y ago
    E.g. GCC does it by mail.
  - keepamovin 3y ago
    I guess there must be a reason for that! It could just be most are used to that way, but I'd like to believe it's somehow "better"! haha :)
- nine_k 3y ago
  If it was so long ago, it likely predates git, and was more painful than it is now. (Git was introduced in 2005, while Linux was first released in 1991; fourteen years separate them.)
  - keepamovin 3y ago
    Indeed, you're right! Yet people still sent patches over email back then, and that is what I meant with "this was how they did it"! :)
    - nine_k 3y ago
      AFAICT projects like OpenBSD still use the same infra: emailed patches and CVS (!).
      - keepamovin 3y ago
        Indeed they do. There's impressively many heavy-duty projects that use it. A great many OSes. There's certainly something to it! :)
        nine_k 3y ago
        Certainly! For one thing, CVS does not allow for such easy rebases and merges as git, so someone has to read your patch carefully, make certain that it merges cleanly, and otherwise pay more attention. This may result in a slower pace, but also in less breakage and a larger shared understanding.
        keepamovin 3y ago
        Nice! Yeah, CVS, I don't know much about it, but your comment reminds me I should check out things outside the git ken! They might just have valuable understandings I need to learn! Thanks for letting me know about it :)
        3y ago
- mikemcquaid 3y ago
  Did you contribute to open source in those days? I did a little (KDE patches to mailing lists before I got Subversion access) and: it was _awful_. You think merging/rebasing/resolving conflicts is a pain now? Doing the same thing via email was _so_ much worse. GitHub has made some parts of open source worse (e.g. how easy it is to now open poor issues while ignoring required information compared to Bugzilla) but the contribution side is so much nicer now. (Bias/context: former GitHub employee, former KDE committer, current Homebrew project leader)
  - dustfinger 3y ago
    > You think merging/rebasing/resolving conflicts is a pain now? Doing the same thing via email was _so_ much worse. Email is just used to receive the patch, you should use a tool meant for the job to actually do the merge. I realize that is probably not what you meant though. Besides, when email patching first began, the tooling was in its infancy. However; today tools like the git cli itself, or magit + smerge-mode (my personal preference) are as good as GitHub, if not better. I never actually use GitHub for merging, even when working on projects hosted in GitHub.
    - beepbooptheory 3y ago
      Spent a long time not even knowing you can resolve merges in github. All I knew was magit and smerge, and assumed people with the fancier editors had something similar.
    - mikemcquaid 3y ago
      > Email is just used to receive the patch, you should use a tool meant for the job to actually do the merge. I know because I also actually did this. You still had to do this locally and then turn it into an email and had no real indication whether someone else had seen/tried/reviewed/etc. it > However; today tools like the git cli itself, or magit + smerge-mode (my personal preference) are as good as GitHub, if not better. I can totally believe for you: this is the case. For most people, though: it will not be. Feel free to prove me wrong by creating a(nother) project that gets thousands of contributors entirely through email. (If you're actually Linus Torvalds, though: you win, I'll shut up now)
manojlds 3y ago
Weird way to list and sort OSs there. Microsoft Windows but last, due to the W I guess but macOS has no Apple in it.
- Etheryte 3y ago
  The official name of the operating system built by Microsoft is Microsoft Windows. For the OS developed by Apple it's macOS. These are their actual names, this has no personal bias in it.
  - dustfinger 3y ago
    I think manojlds point is why the OS names are not sorted by the first word in their name as opposed to the last word in their name. Microsoft Windows should have come right after macOS, if the list was sorted alphabetically by first word, then last. It must be sorted by last, then first though. I guess it is a bit of a strange choice since most OS distributions seem to have a single word for their name, making Microsoft Windows appear miss-sorted.
    - diggan 3y ago
      Windows is 100% in the bottom not because of the name but because it is proprietary. The author of the website (Drew DeVault) is a devout FOSS proponent.
      - intelVISA 3y ago
        Makes sense, objectively it's also the worst OS.
    - kawzeg 3y ago
      If the whole list was sorted last, then first, "Alpine Linux" wouldn't appear first.
      - dustfinger 3y ago
Semaphor 3y ago
Shown to HN on April 2019: https://news.ycombinator.com/item?id=19574257 https://news.ycombinator.com/item?id=19574257
shmichael 3y ago
Amending commits, while having the advantage of keeping the git tree pristine at every single point, is incredibly uncomfortable for async workflows such as the one suggested, where your review might take hours/days and you want to continue coding in a forked branch. Upstreaming any code review changes becomes a pain as git treats the two branches as completely distinct.
- aslatter 3y ago
  That is a pain, but the --update-refs argument to git-rebase helps somewhat: https://git-scm.com/docs/git-rebase#Documentation/git-rebase.txt---update-refs https://git-scm.com/docs/git-rebase#Documentation/git-rebase...
BaculumMeumEst 3y ago
I appreciate the effort here, but after learning the workflow and having to get all this set up on a few computers, having to configure git send-mail is honestly just needlessly annoying and absurd. Organizations that insist on using workflows like git send-mail and mailing lists not only drive away a significant number of potential contributors, but they also form a weirdly religious culture that fetishizes needlessly painful process and is incapable of improvement
- ploum 3y ago
  Organizations that insists on using a web interface and ever-changing click workflows not only drive away a significant number of very knowledgeable contributors, but they also form a weirdly irrational culture that fetishizes needlessly graphical content, marketing and fake-usability detrimental to learnability and integration with each user workflow.
  - sneak 3y ago
    “needlessly graphical” requires a citation when it’s clear that if you use a web GUI for this you address a market of potential contributors that is three to six orders of magnitude larger. srht is really designed for (and thus only really useful for) lone wolf developers who collaborate rarely, if ever, and with a very small number of collaborators who collaborate infrequently. It is not built for large teams with constant active collaboration, it falls down for this use case. It’s hobby software for hobby users. (I don’t think this is a bad thing, but you should be aware of the product design goals of its author.)
    - ploum 3y ago
      [flagged]
      - sneak 3y ago
        That’s your bias showing; GitHub is primarily designed for getting work done, as it is a paid service that needs to serve its customers.
MatthiasPortzel 3y ago
> Warning! Some people think that they can get away with sending patches through some means other than git send-email, but you can't. Could someone elaborate on this? Obviously it’s not intended, but is there anything wrong, from a technical standpoint, with using `git format-patch`, zipping the result, attaching it to an email using a GUI email client, and sending it to a maintainer who unzips and runs `git am`?
- bonzini 3y ago
  The point is being able to discuss and archive things via email. Using a zip file makes this moot.
- tlamponi 3y ago
  The core reason for this is that lots (all?) of "modern" mail user agents (MUA) mess with whitespace in their default configuration, which breaks patches as the indentation is all of and git is confused. git send-email is made for this, and handles all edge cases correctly, but depending on your MUA and/or it's config, it can work pasting patch diffs in there just fine – the point is that, especially for newcomers, and for a few edge cases, it may hard to do correctly and so using the tool made for the job avoids friction for all sites. ps. ZIP wouldn't be required, just use base64 encoding, that's basically what git send-email does, depending on the encoding, line length, ... of a commit.
- catern 3y ago
  That specific workflow precludes reviewing the patch via quoting and making inline comments, which is the normal way to review patches when sending them via email.
- diggan 3y ago
  Zipping the patch kind of works around the issue but introduces probable workflow-incompatibilities, maintainers expect the patch itself in the email, not a compressed archive of the patch. Re sending patches in email clients without using send-email, some clients (famously Outlook) try to be "helpful" and for example remove blank lines (double or single, don't remember) for example and will corrupt the patch in the process.
lusus_naturae 3y ago
Seems like you're sending plain text emails, no? I have links for websites, resume etc. in the signature so I am not sure how this is conducive to that. Unless there is a method to add a signature with links?
- barryrandall 3y ago
  There are lots of reasons to go plain text only, and stripping links and images from signatures is often in the top 10.
  - lusus_naturae 3y ago
    That's fair, the links I put in mine are to my lab and own websites. I am not aware of any better way to share that info other than maybe tiny urls.
webdevver 3y ago
I wish I could "preview" sending my patch to mailing lists. I've considered the idea of having a localhost mailing list for the sole purpose of sending it there just to make sure that i've got everything setup right, but haven't gotten around to doing it yet.
- diggan 3y ago
  If you just want to preview the patch itself you can generate it and preview/test use it by doing "git diff > my-own-patch.patch", which would be identical to the patch that "git send-email" would attach to your email. You can apply it with "git apply my-own-patch.patch" for example. People generally are helpful if it's your first time contributing, so if someone isn't right, I'm sure someone will help you get it right.
- LegionMammal978 3y ago
  I've found a way to "preview" emails without too much preparatory hassle, at least on Gmail that allows adding suffixes to your address after a + sign. After you finish writing the email, rewrite all the addresses in the To: and Cc: lines so instead of pointing to foo@example.com, they point to myaddress+foo+example.com@gmail.com. Then, once you send it, you can check the version in your inbox to make sure everything is correct, and undo the rewrite to send the email for real.
- gwd 3y ago
  git send-email --dry-run <commitish> will show you the mail headers it would have generated (including subject lines, To: and Cc: fields). git format-patch -o<tempdir> <committish> will create a separate mail-like file for each patch in <tempdir>. Finally, git format-patch --stdout <committish> > foo.mbox will (I think) generate something which something capable of reading mbox'es should be able to read. (The latter I may be remembering incorrectly, but worth giving a try.)
haolez 3y ago
Why not use a branch? This was the only surprisingly part to me. Won't this get messy when I try to pull the code later on? I don't know how the maintainer is going to merge my patch.
- diggan 3y ago
  You could do it in a branch if you want to, doesn't matter, as long as the diff/patch is based on the branch where upstream does its main work.
ligurio 3y ago
I appreciate the effort here, but in the proposed workflow are missed steps with subscribing to a mailing list. Without proper subscriptions and confirming subscription, your mails with patches will go to trash.
- emersion 3y ago
  That's not true in general. Many mailing lists accept emails from unsubscribed users, some moderate them (requiring moderator approval for the first post), but I don't know of any which outright rejects such emails.
  - Avamander 3y ago
    I might be remembering wrong but I think hostapd's list rejects like that. In any case, even the possibility of such an outcome is not pleasant.
tormeh 3y ago
Is there any collaboration tool (reviews, etc.) that uses git itself to sync the status? Adding email or whatever seems unnecessary, and github et al. seem contrary to the spirit of git.
- AlphaWeaver 3y ago
  In theory modern Gerrit supports this, by storing review metadata in Git notes attached to the repository. Most of the time though, people still use the Web UI.
samcat116 3y ago
Not really a huge fan of this whole method, but the GitHub CLI is really well thought out and means I basically never need to leave the terminal if I don't want to.
- toastal 3y ago
  How will that CLI work when using non-proprietary Git (or other VCS) servers? Sounds like a way to get stuck in walled garden.
- keep_reading 3y ago
  > but the GitHub CLI is really well thought How do you get to that conclusion? https://stevelosh.com/blog/2013/04/git-koans/ https://stevelosh.com/blog/2013/04/git-koans/
  - dagw 3y ago
    The GitHub CLI is a completely different tool than the git CLI https://cli.github.com https://cli.github.com
- myaccountonhn 3y ago
  Each command is sooooo slow though compared to offline synced mail
gwd 3y ago
One thing this is missing is cover letters for longer series. Last time I checked that was the biggest pain: the fact that there's no real convenient way to store the cover letters; `git send-email --cover` will expect you to compose a new one every time.
talent_deprived 3y ago
Oh, I thought this was like a PR notification system, it's to actually send the diff to an email list. And the recipients would pull in those changes from the email? I think that's kind of how things worked a long time ago IIRC. Is the goal that this would be as official as how we push to remote, then file a PR now? Actually, if you want to cut out all the systems like github or git lab, why wouldn't the team just set up a VPS with standard ssh access and that would be the main repo people push to since git supports many protocols like ssh, and even file:// (which I use for my local projects which are backed up). It's easy for the VPS admin to add new team members, just a standard Linux account. It might be possible to even set up a restricted account so the member ssh'ing in a commit using git only has access to the repo and can't get a login shell.
stockhorn 3y ago
off topic, but why does the page (step 2) rant about protonmail? Can somebody elaborate? >Be advised that Protonmail is generally known to be a pretty bad email host. [...] Not to mention their mistreatment of open source and false promises of security! You should consider a different mail provider.
- protonmail 3y ago
  Proton Mail Bridge normalizes line breaks in plaintext emails to conform with cleartext PGP signing rules. This sometimes creates problems with third-party cleartext signing which is used by programs such as git-send-email. Third-party signing is not actually a supported use case of the Bridge and this can be worked around by requesting a SMTP submission token.
IsaacSchlueter 3y ago
I enjoy tutorials like this, in the same way and for the same reasons that I enjoy videos where people make cutting tools out of obsidian that they chip by hand. Personally, though, when I have to actually cut something, I use stainless steel knives or scissors, which are cheap and readily available and do a much better job. Same with pull requests. But historical reenactment can be a fun pastime.
ryanisnan 3y ago
Email-driven contribution systems, no thanks. Why anyone would, in 2023, elect to use email as the backbone for their development processes eludes me.
- myaccountonhn 3y ago
  It’s fantastic once setup. Almost all systems have email notifications, many allowing you to respond from email. if you have an email client that integrates with your editor then it gives you a source of truth for all notifications which you can easily reference.
thayne 3y ago
I've used email-based workflow for a few contributions I've made. The git-send-email part isn't too bad. It's everything else I have a problem with: - You can't subscribe to a single PR/bug/feature-request thread. Subscription to the mailing list is all-or-nothing. And no, setting up email filters is not a reasonable solution. - Email clients are pretty much universally terrible. Especially if you want to use the same client for your git flow as you do for regular email. Most clients don't handle inline-replies well, and require some extra work to send plain text emails. Clients that do work well for that often have a steep learning curve, and are missing features if you want to use it for general email. - The flow for "Dealing with feedback" in this tutorial will start a new email thread instead of replying to the existing one. There is a way to reply to an existing thread with send-email, but it is kind of involved since you have to look up the message id of the email you are replying to (which may or may not be easy depending on your email client). And even then, I've had mixed success with it. - Although I haven't been on the other side of it, it seems like reviewing the patch would be somewhat difficult without additional tooling. Especially comparing new versions dealing with feedback to the original version. - Again, I haven't been on that side of it, but it seems like applying the changes from an email would be a bit of a pain compared to just pressing "merge". - You can run into issues if your lines of code are more than 78 characters long. I used git-send-email to send in a patch once that had this, but the email client of the receiver couldn't handle long lines, so I had to resend it with the patch as an attachment. - Some mailing lists require you to subscribe before you can send a patch. And if the list is pretty active, that can flood your inbox. See my first point. - etc.
- tlamponi 3y ago
  You have some points, for some I do think it isn't as bad as you write. FWIW, some comments inline. > - You can't subscribe to a single PR/bug/feature-request thread. Subscription to the mailing list is all-or-nothing. And no, setting up email filters is not a reasonable solution. You can use tools like public-inbox or lei, the former is hosted for bigger projects on https://lore.kernel.org/ https://lore.kernel.org/ If you're interested, see also https://people.kernel.org/monsieuricon/lore-lei-part-1-getting-started https://people.kernel.org/monsieuricon/lore-lei-part-1-getti... And sure subscribing for a drive by submission is rather overkill, but if one contributes more than a few patches, setting up a filter is to easy with mailing lists that I don't think one can just hand wave that away as an "unreasonable" solution. List have a dedicated List-Id header, so one can easily filter them in a targeted way. What I want to convey actually is, that yes, there can be improvements made here, but doing so isn't impossible just because the message medium is decentralized mail vs. a centralized HTTP API. - Email clients are pretty much universally terrible. Especially if you want to use the same client for your git flow as you do for regular email. Most clients don't handle inline-replies well, and require some extra work to send plain text emails. Clients that do work well for that often have a steep learning curve, and are missing features if you want to use it for general email. Hard disagree on that being the general case. Even getting Thunderbird to send plaintext is simple and only one setting, and there are mailers like aerc [0] or neomutt that are really well suited for an integrated mail + apply + review setup. But sure, there are some bad apples, especially most web mailer. [0]: https://aerc-mail.org/ https://aerc-mail.org/ [1]: https://neomutt.org/ https://neomutt.org/ > - The flow for "Dealing with feedback" in this tutorial will start a new email thread instead of replying to the existing one. Yes, for sending a new revision this is highly wanted – please do NOT send new patch revision to the same thread, that just crowds review and adds nothing. Simply add a changelog to the previous revision in the cover-letter and/or in each patch, i.e., after the message, below "--" and before the diff-stat, as there they won't get into git, such changes are meta info relevant for review, not for the git history. > - Although I haven't been on the other side of it, it seems like reviewing the patch would be somewhat difficult without additional tooling. Especially comparing new versions dealing with feedback to the original version. I have reviewed lots of patches via mailing list, it's really nice and depending on the patch one can review directly inline or apply (save + `git am`, or directly `git am` depending on your mailer). IMO much higher quality of life than with the classic Git(La|Hu)b forges. > - Again, I haven't been on that side of it, but it seems like applying the changes from an email would be a bit of a pain compared to just pressing "merge". No it really isn't, I'm doing that since years a dozen+ time a day, and it is as easy now as it was back then when I started. If I use thunderbird I got my one directory for it, so I just mark all, save and execute `git am ~/t/aaa/*` in the repo. When I use aerc, then it's even simpler, it has built-in helpers for doing this easily. Here I can manage simple conflicts easily (e.g., using three-way-merge) on GitHub conflicts are a bigger PITA and need lots of manual intervention from me or waiting on the submitter, meh. Also, the interface often loads weirdly, as they manage their own history as a single page app which often gets in a state where button presses won't do much. > - You can run into issues if your lines of code are more than 78 characters long. I used git-send-email to send in a patch once that had this, but the email client of the receiver couldn't handle long lines, so I had to resend it with the patch as an attachment. git send-email uses base64 encoding for that, if the mail user agent of your recipient cannot handle that it's like their broswer cannot handle HTTP/1.1, switch that stuff immediately. > - Some mailing lists require you to subscribe before you can send a patch. And if the list is pretty active, that can flood your inbox. See my first point. Yeah, sadly sometimes needed for anti-spam measurements, here I agree fully that this isn't ideal, but FWIW, for Git(Hu|La)b I also need to create a account and fork, so it's not exactly zero work there too, but yeah, due to SSO and gaining access to many projects, vs. just one for a subscription that is not really comparable..
jchw 3y ago
Personally, I enjoyed using Git with e-mail when Wine still used it. That said, the major improvement of moving to GitLab is that it's now easier to track changesets individually, as there is now a single place to look for a given changeset, rather than having to follow chains of e-mails. And that having been said, I really GitHub/GitLab/etc. could move on from the pull request model and into a more change-oriented model like Gerrit or Phabricator. These are clearly better models in my opinion, and for most uses it's not even dramatically different.
deleted 3y ago
[deleted]
pyrolistical 3y ago
This is the fediverse they want
darau1 3y ago
Just dropping this gem of a talk[1], for the uninitiated. There is a place for this, even if people in the thread have never seen it. [1]: https://www.youtube.com/watch?v=vyenmLqJQjs https://www.youtube.com/watch?v=vyenmLqJQjs
mvdtnz 3y ago
The world has moved on. Products like Github and Gitlab supercharge these capabilities so far beyond what the Linux Core team are doing with their email lists.
Am4TIfIsER0ppos 3y ago
Too bad google has disabled "insecure apps" meaning I have a couple of ffmpeg patches sitting around because I haven't yet migrated it to my own domain. I thinking of sending from "FuckYouGoogle".
- toastal 3y ago
  If this caused more folks to jump ship away from letting Google read all of their messages (as well as mine from the other end), then I’m all for it.
da39a3ee 3y ago
Please do not contribute to this silly archaic practice. It was once not silly. It is now archaic, and it is silly to do it now that we have vastly superior tools.
keep_reading 3y ago
This is so absurd. The complexity of this setup is off the charts. If you thought memorizing terrible inconsistent git commands was bad enough, this just cranks it to 11

289 points by pmarin 3y ago

It is way faster and easier for me to just open up my email client, attach a patch, and send it.

Not related to Git + git-email. I just want to say that I love the way this website is structured. Also, it renders fast.

mkmk 3y ago
It’s miserable on mobile. Confusing unlabeled next button at the bottom of the page, plus an orange next button that seems to do the same thing but sometimes randomly overlaps the content. Why not have all the content on one page?
- dsaravel 3y ago
  I did not test on mobile and maybe it should have all the steps in single page for that aspect ratio (easier to simply scroll). However, for desktop, it was such a beautiful way to guide the reader each step of the way. It was really well done.

keepamovin 3y ago

I love this. This is how it was done back in the days of usenet. People would email patches to the linux kernel. Hackers, working alone, late at night, strange times, strange places. Cultivating their work and skills and then ... shoot ... sending an email! Their contribution. So cool! Maybe we should go back to this. Get rid of the whole github thing. Every group their own little mailing list. Laboring in private!

dewey 3y ago
> Hackers, working alone, late at night, strange times, strange places. Cultivating their work and skills and then ... shoot ... sending an email! Very poetic, but also not much different to the current state. Just clicking to open a PR instead of sending an email attachment.
- nkjoep 3y ago
  correct. Opening a PR triggers an email. No difference at all.
- keepamovin 3y ago
  :) Thank you! I guess I prefer text. And deeply there's a difference between staying in text, and moving to GUI. The medium is the message^0, and even if the process is "the same", everything becomes different because you're no longer within the text world. 0: https://en.wikipedia.org/wiki/The_medium_is_the_message https://en.wikipedia.org/wiki/The_medium_is_the_message
  - dewey 3y ago
    I know it's not the same, but that's also why I prefer GitLab's "--push-option=merge_request.create" which creates a PR from the CLI without needing me to open the website and clicking a button. I'm still annoyed daily that this doesn't exist for GitHub.
    - pjm331 3y ago
      GitHub has a CLI https://cli.github.com/manual/gh_pr_create https://cli.github.com/manual/gh_pr_create
      - dewey 3y ago
        Yes, but the advantage with the "push options" is that I can put it in my .gitconfig and it just works automatically when I do a git push without using some proprietary platform's cli.
    - 3y ago
yankput 3y ago
sr.ht does that I don’t find it very user friendly (well, at all), but if you want a git forge that does that, you can use it.
- junon 3y ago
  This is my experience as well. I love the hacker culture associated with it and it's very fun to use e.g. Mutt, sr.ht, and git-send-email together, but it's anything but efficient and straightforward. I ultimately moved away from sr.ht for that reason.
  - ploum 3y ago
    Some, like myself, find the mouse really painful to use and hate graphical interfaces when you have to randomly click to find something (while you can read a man page, grep through it and then automatize the process in custom scripts). But it is not only about efficiency. It is about control and centralisation. Git-send-mail works everywhere there’s an email. It allows people to use the tool they prefer. It allows them to build custom tools. It doesn’t make people dependent from a forge (you are a simple "git remote set-url" away from using a new forge). Github forces everybody to use the same graphical interface which requires tons of JS and lot of CPU. Github forces you to accept all their changes. Github forces you to be a slave of Microsoft and contribute all your code to their IA training set. Github forces you to be notificed of stuff you don’t care. The "Hacker culture" is first and foremost about personal freedom. And if you believe the tool are not efficient, as a true hacker, you will built others (but, spoiler, most of the time, when you become proficient enough to build you own tools, you realize how efficient the existing ones are). Hacking is like walking. You look at walkers and you think it looks tiring to walk. So you go to the parking lot. You start your car. You go through the gate and give your driver license to the cop controlling you. You then go to the gas station. You pay with you credit card. There’s an accident in front of you, you are stuck in the traffic. You take your Google controlled GPS and ask for another itinerary. You drive. You wait at a red light, looking at your phone. A notification to pay the insurance of the car. Another one to pay for the leasing of the car itself. A light blink on the dashboard: you need to add oil and do the annual checkup of the car. You drive, you are a bit stressed and go too fast. You see a flash. Shit! Will I get a ticket? I was not that fast? You arrive at destination. There’s no room left in the parking. You start to drive around, hoping for a spot. There! You get it. It is bit small. You hope that nobody will scratch your car. For whatever reason, you learned that cars can’t be scratched so you are very careful. You get out of the car and walk a bit to the destination. Then you see them… The walkers. They went here by foot, through a path in the forest. They are smiling, even if they was some light rain. And you ask them: "Why don’t you guys get a car? Seriously? Walking is hard and inefficient. I can’t walk myself for than 1km before getting my legs sore."
terminalcommand 3y ago
Many oss projects still do this, don't they. I am subscribed to debian and python mail lists. Debian's lists are highly active.
- rightbyte 3y ago
  E.g. GCC does it by mail.
- keepamovin 3y ago
  I guess there must be a reason for that! It could just be most are used to that way, but I'd like to believe it's somehow "better"! haha :)
nine_k 3y ago
If it was so long ago, it likely predates git, and was more painful than it is now. (Git was introduced in 2005, while Linux was first released in 1991; fourteen years separate them.)
- keepamovin 3y ago
  Indeed, you're right! Yet people still sent patches over email back then, and that is what I meant with "this was how they did it"! :)
  - nine_k 3y ago
    AFAICT projects like OpenBSD still use the same infra: emailed patches and CVS (!).
    - keepamovin 3y ago
      Indeed they do. There's impressively many heavy-duty projects that use it. A great many OSes. There's certainly something to it! :)
      - nine_k 3y ago
        Certainly! For one thing, CVS does not allow for such easy rebases and merges as git, so someone has to read your patch carefully, make certain that it merges cleanly, and otherwise pay more attention. This may result in a slower pace, but also in less breakage and a larger shared understanding.
        keepamovin 3y ago
        Nice! Yeah, CVS, I don't know much about it, but your comment reminds me I should check out things outside the git ken! They might just have valuable understandings I need to learn! Thanks for letting me know about it :)
        3y ago
mikemcquaid 3y ago
Did you contribute to open source in those days? I did a little (KDE patches to mailing lists before I got Subversion access) and: it was _awful_. You think merging/rebasing/resolving conflicts is a pain now? Doing the same thing via email was _so_ much worse. GitHub has made some parts of open source worse (e.g. how easy it is to now open poor issues while ignoring required information compared to Bugzilla) but the contribution side is so much nicer now. (Bias/context: former GitHub employee, former KDE committer, current Homebrew project leader)
- dustfinger 3y ago
  > You think merging/rebasing/resolving conflicts is a pain now? Doing the same thing via email was _so_ much worse. Email is just used to receive the patch, you should use a tool meant for the job to actually do the merge. I realize that is probably not what you meant though. Besides, when email patching first began, the tooling was in its infancy. However; today tools like the git cli itself, or magit + smerge-mode (my personal preference) are as good as GitHub, if not better. I never actually use GitHub for merging, even when working on projects hosted in GitHub.
  - beepbooptheory 3y ago
    Spent a long time not even knowing you can resolve merges in github. All I knew was magit and smerge, and assumed people with the fancier editors had something similar.
  - mikemcquaid 3y ago
    > Email is just used to receive the patch, you should use a tool meant for the job to actually do the merge. I know because I also actually did this. You still had to do this locally and then turn it into an email and had no real indication whether someone else had seen/tried/reviewed/etc. it > However; today tools like the git cli itself, or magit + smerge-mode (my personal preference) are as good as GitHub, if not better. I can totally believe for you: this is the case. For most people, though: it will not be. Feel free to prove me wrong by creating a(nother) project that gets thousands of contributors entirely through email. (If you're actually Linus Torvalds, though: you win, I'll shut up now)

manojlds 3y ago

Weird way to list and sort OSs there. Microsoft Windows but last, due to the W I guess but macOS has no Apple in it.

Etheryte 3y ago
The official name of the operating system built by Microsoft is Microsoft Windows. For the OS developed by Apple it's macOS. These are their actual names, this has no personal bias in it.
- dustfinger 3y ago
  I think manojlds point is why the OS names are not sorted by the first word in their name as opposed to the last word in their name. Microsoft Windows should have come right after macOS, if the list was sorted alphabetically by first word, then last. It must be sorted by last, then first though. I guess it is a bit of a strange choice since most OS distributions seem to have a single word for their name, making Microsoft Windows appear miss-sorted.
  - diggan 3y ago
    Windows is 100% in the bottom not because of the name but because it is proprietary. The author of the website (Drew DeVault) is a devout FOSS proponent.
    - intelVISA 3y ago
      Makes sense, objectively it's also the worst OS.
  - kawzeg 3y ago
    If the whole list was sorted last, then first, "Alpine Linux" wouldn't appear first.
    - dustfinger 3y ago

Semaphor 3y ago

Shown to HN on April 2019: https://news.ycombinator.com/item?id=19574257 https://news.ycombinator.com/item?id=19574257

shmichael 3y ago

Amending commits, while having the advantage of keeping the git tree pristine at every single point, is incredibly uncomfortable for async workflows such as the one suggested, where your review might take hours/days and you want to continue coding in a forked branch. Upstreaming any code review changes becomes a pain as git treats the two branches as completely distinct.

aslatter 3y ago
That is a pain, but the --update-refs argument to git-rebase helps somewhat: https://git-scm.com/docs/git-rebase#Documentation/git-rebase.txt---update-refs https://git-scm.com/docs/git-rebase#Documentation/git-rebase...

BaculumMeumEst 3y ago

I appreciate the effort here, but after learning the workflow and having to get all this set up on a few computers, having to configure git send-mail is honestly just needlessly annoying and absurd. Organizations that insist on using workflows like git send-mail and mailing lists not only drive away a significant number of potential contributors, but they also form a weirdly religious culture that fetishizes needlessly painful process and is incapable of improvement

ploum 3y ago
Organizations that insists on using a web interface and ever-changing click workflows not only drive away a significant number of very knowledgeable contributors, but they also form a weirdly irrational culture that fetishizes needlessly graphical content, marketing and fake-usability detrimental to learnability and integration with each user workflow.
- sneak 3y ago
  “needlessly graphical” requires a citation when it’s clear that if you use a web GUI for this you address a market of potential contributors that is three to six orders of magnitude larger. srht is really designed for (and thus only really useful for) lone wolf developers who collaborate rarely, if ever, and with a very small number of collaborators who collaborate infrequently. It is not built for large teams with constant active collaboration, it falls down for this use case. It’s hobby software for hobby users. (I don’t think this is a bad thing, but you should be aware of the product design goals of its author.)
  - ploum 3y ago
    [flagged]
    - sneak 3y ago
      That’s your bias showing; GitHub is primarily designed for getting work done, as it is a paid service that needs to serve its customers.

MatthiasPortzel 3y ago

> Warning! Some people think that they can get away with sending patches through some means other than git send-email, but you can't. Could someone elaborate on this? Obviously it’s not intended, but is there anything wrong, from a technical standpoint, with using `git format-patch`, zipping the result, attaching it to an email using a GUI email client, and sending it to a maintainer who unzips and runs `git am`?

bonzini 3y ago
The point is being able to discuss and archive things via email. Using a zip file makes this moot.
tlamponi 3y ago
The core reason for this is that lots (all?) of "modern" mail user agents (MUA) mess with whitespace in their default configuration, which breaks patches as the indentation is all of and git is confused. git send-email is made for this, and handles all edge cases correctly, but depending on your MUA and/or it's config, it can work pasting patch diffs in there just fine – the point is that, especially for newcomers, and for a few edge cases, it may hard to do correctly and so using the tool made for the job avoids friction for all sites. ps. ZIP wouldn't be required, just use base64 encoding, that's basically what git send-email does, depending on the encoding, line length, ... of a commit.
catern 3y ago
That specific workflow precludes reviewing the patch via quoting and making inline comments, which is the normal way to review patches when sending them via email.
diggan 3y ago
Zipping the patch kind of works around the issue but introduces probable workflow-incompatibilities, maintainers expect the patch itself in the email, not a compressed archive of the patch. Re sending patches in email clients without using send-email, some clients (famously Outlook) try to be "helpful" and for example remove blank lines (double or single, don't remember) for example and will corrupt the patch in the process.

lusus_naturae 3y ago

Seems like you're sending plain text emails, no? I have links for websites, resume etc. in the signature so I am not sure how this is conducive to that. Unless there is a method to add a signature with links?

barryrandall 3y ago
There are lots of reasons to go plain text only, and stripping links and images from signatures is often in the top 10.
- lusus_naturae 3y ago
  That's fair, the links I put in mine are to my lab and own websites. I am not aware of any better way to share that info other than maybe tiny urls.

webdevver 3y ago

I wish I could "preview" sending my patch to mailing lists. I've considered the idea of having a localhost mailing list for the sole purpose of sending it there just to make sure that i've got everything setup right, but haven't gotten around to doing it yet.

diggan 3y ago
If you just want to preview the patch itself you can generate it and preview/test use it by doing "git diff > my-own-patch.patch", which would be identical to the patch that "git send-email" would attach to your email. You can apply it with "git apply my-own-patch.patch" for example. People generally are helpful if it's your first time contributing, so if someone isn't right, I'm sure someone will help you get it right.
LegionMammal978 3y ago
I've found a way to "preview" emails without too much preparatory hassle, at least on Gmail that allows adding suffixes to your address after a + sign. After you finish writing the email, rewrite all the addresses in the To: and Cc: lines so instead of pointing to foo@example.com, they point to myaddress+foo+example.com@gmail.com. Then, once you send it, you can check the version in your inbox to make sure everything is correct, and undo the rewrite to send the email for real.
gwd 3y ago
git send-email --dry-run <commitish> will show you the mail headers it would have generated (including subject lines, To: and Cc: fields). git format-patch -o<tempdir> <committish> will create a separate mail-like file for each patch in <tempdir>. Finally, git format-patch --stdout <committish> > foo.mbox will (I think) generate something which something capable of reading mbox'es should be able to read. (The latter I may be remembering incorrectly, but worth giving a try.)

haolez 3y ago

Why not use a branch? This was the only surprisingly part to me. Won't this get messy when I try to pull the code later on? I don't know how the maintainer is going to merge my patch.

diggan 3y ago
You could do it in a branch if you want to, doesn't matter, as long as the diff/patch is based on the branch where upstream does its main work.

ligurio 3y ago

I appreciate the effort here, but in the proposed workflow are missed steps with subscribing to a mailing list. Without proper subscriptions and confirming subscription, your mails with patches will go to trash.

emersion 3y ago
That's not true in general. Many mailing lists accept emails from unsubscribed users, some moderate them (requiring moderator approval for the first post), but I don't know of any which outright rejects such emails.
- Avamander 3y ago
  I might be remembering wrong but I think hostapd's list rejects like that. In any case, even the possibility of such an outcome is not pleasant.

tormeh 3y ago

Is there any collaboration tool (reviews, etc.) that uses git itself to sync the status? Adding email or whatever seems unnecessary, and github et al. seem contrary to the spirit of git.

AlphaWeaver 3y ago
In theory modern Gerrit supports this, by storing review metadata in Git notes attached to the repository. Most of the time though, people still use the Web UI.

samcat116 3y ago

Not really a huge fan of this whole method, but the GitHub CLI is really well thought out and means I basically never need to leave the terminal if I don't want to.

toastal 3y ago
How will that CLI work when using non-proprietary Git (or other VCS) servers? Sounds like a way to get stuck in walled garden.
keep_reading 3y ago
> but the GitHub CLI is really well thought How do you get to that conclusion? https://stevelosh.com/blog/2013/04/git-koans/ https://stevelosh.com/blog/2013/04/git-koans/
- dagw 3y ago
  The GitHub CLI is a completely different tool than the git CLI https://cli.github.com https://cli.github.com
myaccountonhn 3y ago
Each command is sooooo slow though compared to offline synced mail

gwd 3y ago

One thing this is missing is cover letters for longer series. Last time I checked that was the biggest pain: the fact that there's no real convenient way to store the cover letters; `git send-email --cover` will expect you to compose a new one every time.

talent_deprived 3y ago

Oh, I thought this was like a PR notification system, it's to actually send the diff to an email list. And the recipients would pull in those changes from the email? I think that's kind of how things worked a long time ago IIRC. Is the goal that this would be as official as how we push to remote, then file a PR now? Actually, if you want to cut out all the systems like github or git lab, why wouldn't the team just set up a VPS with standard ssh access and that would be the main repo people push to since git supports many protocols like ssh, and even file:// (which I use for my local projects which are backed up). It's easy for the VPS admin to add new team members, just a standard Linux account. It might be possible to even set up a restricted account so the member ssh'ing in a commit using git only has access to the repo and can't get a login shell.

stockhorn 3y ago

off topic, but why does the page (step 2) rant about protonmail? Can somebody elaborate? >Be advised that Protonmail is generally known to be a pretty bad email host. [...] Not to mention their mistreatment of open source and false promises of security! You should consider a different mail provider.

protonmail 3y ago
Proton Mail Bridge normalizes line breaks in plaintext emails to conform with cleartext PGP signing rules. This sometimes creates problems with third-party cleartext signing which is used by programs such as git-send-email. Third-party signing is not actually a supported use case of the Bridge and this can be worked around by requesting a SMTP submission token.

IsaacSchlueter 3y ago

I enjoy tutorials like this, in the same way and for the same reasons that I enjoy videos where people make cutting tools out of obsidian that they chip by hand. Personally, though, when I have to actually cut something, I use stainless steel knives or scissors, which are cheap and readily available and do a much better job. Same with pull requests. But historical reenactment can be a fun pastime.

ryanisnan 3y ago

Email-driven contribution systems, no thanks. Why anyone would, in 2023, elect to use email as the backbone for their development processes eludes me.

myaccountonhn 3y ago
It’s fantastic once setup. Almost all systems have email notifications, many allowing you to respond from email. if you have an email client that integrates with your editor then it gives you a source of truth for all notifications which you can easily reference.

thayne 3y ago

I've used email-based workflow for a few contributions I've made. The git-send-email part isn't too bad. It's everything else I have a problem with: - You can't subscribe to a single PR/bug/feature-request thread. Subscription to the mailing list is all-or-nothing. And no, setting up email filters is not a reasonable solution. - Email clients are pretty much universally terrible. Especially if you want to use the same client for your git flow as you do for regular email. Most clients don't handle inline-replies well, and require some extra work to send plain text emails. Clients that do work well for that often have a steep learning curve, and are missing features if you want to use it for general email. - The flow for "Dealing with feedback" in this tutorial will start a new email thread instead of replying to the existing one. There is a way to reply to an existing thread with send-email, but it is kind of involved since you have to look up the message id of the email you are replying to (which may or may not be easy depending on your email client). And even then, I've had mixed success with it. - Although I haven't been on the other side of it, it seems like reviewing the patch would be somewhat difficult without additional tooling. Especially comparing new versions dealing with feedback to the original version. - Again, I haven't been on that side of it, but it seems like applying the changes from an email would be a bit of a pain compared to just pressing "merge". - You can run into issues if your lines of code are more than 78 characters long. I used git-send-email to send in a patch once that had this, but the email client of the receiver couldn't handle long lines, so I had to resend it with the patch as an attachment. - Some mailing lists require you to subscribe before you can send a patch. And if the list is pretty active, that can flood your inbox. See my first point. - etc.

tlamponi 3y ago
You have some points, for some I do think it isn't as bad as you write. FWIW, some comments inline. > - You can't subscribe to a single PR/bug/feature-request thread. Subscription to the mailing list is all-or-nothing. And no, setting up email filters is not a reasonable solution. You can use tools like public-inbox or lei, the former is hosted for bigger projects on https://lore.kernel.org/ https://lore.kernel.org/ If you're interested, see also https://people.kernel.org/monsieuricon/lore-lei-part-1-getting-started https://people.kernel.org/monsieuricon/lore-lei-part-1-getti... And sure subscribing for a drive by submission is rather overkill, but if one contributes more than a few patches, setting up a filter is to easy with mailing lists that I don't think one can just hand wave that away as an "unreasonable" solution. List have a dedicated List-Id header, so one can easily filter them in a targeted way. What I want to convey actually is, that yes, there can be improvements made here, but doing so isn't impossible just because the message medium is decentralized mail vs. a centralized HTTP API. - Email clients are pretty much universally terrible. Especially if you want to use the same client for your git flow as you do for regular email. Most clients don't handle inline-replies well, and require some extra work to send plain text emails. Clients that do work well for that often have a steep learning curve, and are missing features if you want to use it for general email. Hard disagree on that being the general case. Even getting Thunderbird to send plaintext is simple and only one setting, and there are mailers like aerc [0] or neomutt that are really well suited for an integrated mail + apply + review setup. But sure, there are some bad apples, especially most web mailer. [0]: https://aerc-mail.org/ https://aerc-mail.org/ [1]: https://neomutt.org/ https://neomutt.org/ > - The flow for "Dealing with feedback" in this tutorial will start a new email thread instead of replying to the existing one. Yes, for sending a new revision this is highly wanted – please do NOT send new patch revision to the same thread, that just crowds review and adds nothing. Simply add a changelog to the previous revision in the cover-letter and/or in each patch, i.e., after the message, below "--" and before the diff-stat, as there they won't get into git, such changes are meta info relevant for review, not for the git history. > - Although I haven't been on the other side of it, it seems like reviewing the patch would be somewhat difficult without additional tooling. Especially comparing new versions dealing with feedback to the original version. I have reviewed lots of patches via mailing list, it's really nice and depending on the patch one can review directly inline or apply (save + `git am`, or directly `git am` depending on your mailer). IMO much higher quality of life than with the classic Git(La|Hu)b forges. > - Again, I haven't been on that side of it, but it seems like applying the changes from an email would be a bit of a pain compared to just pressing "merge". No it really isn't, I'm doing that since years a dozen+ time a day, and it is as easy now as it was back then when I started. If I use thunderbird I got my one directory for it, so I just mark all, save and execute `git am ~/t/aaa/*` in the repo. When I use aerc, then it's even simpler, it has built-in helpers for doing this easily. Here I can manage simple conflicts easily (e.g., using three-way-merge) on GitHub conflicts are a bigger PITA and need lots of manual intervention from me or waiting on the submitter, meh. Also, the interface often loads weirdly, as they manage their own history as a single page app which often gets in a state where button presses won't do much. > - You can run into issues if your lines of code are more than 78 characters long. I used git-send-email to send in a patch once that had this, but the email client of the receiver couldn't handle long lines, so I had to resend it with the patch as an attachment. git send-email uses base64 encoding for that, if the mail user agent of your recipient cannot handle that it's like their broswer cannot handle HTTP/1.1, switch that stuff immediately. > - Some mailing lists require you to subscribe before you can send a patch. And if the list is pretty active, that can flood your inbox. See my first point. Yeah, sadly sometimes needed for anti-spam measurements, here I agree fully that this isn't ideal, but FWIW, for Git(Hu|La)b I also need to create a account and fork, so it's not exactly zero work there too, but yeah, due to SSO and gaining access to many projects, vs. just one for a subscription that is not really comparable..

jchw 3y ago

Personally, I enjoyed using Git with e-mail when Wine still used it. That said, the major improvement of moving to GitLab is that it's now easier to track changesets individually, as there is now a single place to look for a given changeset, rather than having to follow chains of e-mails. And that having been said, I really GitHub/GitLab/etc. could move on from the pull request model and into a more change-oriented model like Gerrit or Phabricator. These are clearly better models in my opinion, and for most uses it's not even dramatically different.

deleted 3y ago

[deleted]

pyrolistical 3y ago

This is the fediverse they want

darau1 3y ago

Just dropping this gem of a talk[1], for the uninitiated. There is a place for this, even if people in the thread have never seen it. [1]: https://www.youtube.com/watch?v=vyenmLqJQjs https://www.youtube.com/watch?v=vyenmLqJQjs

mvdtnz 3y ago

The world has moved on. Products like Github and Gitlab supercharge these capabilities so far beyond what the Linux Core team are doing with their email lists.

Am4TIfIsER0ppos 3y ago

Too bad google has disabled "insecure apps" meaning I have a couple of ffmpeg patches sitting around because I haven't yet migrated it to my own domain. I thinking of sending from "FuckYouGoogle".

toastal 3y ago
If this caused more folks to jump ship away from letting Google read all of their messages (as well as mine from the other end), then I’m all for it.

da39a3ee 3y ago

Please do not contribute to this silly archaic practice. It was once not silly. It is now archaic, and it is silly to do it now that we have vastly superior tools.

keep_reading 3y ago

This is so absurd. The complexity of this setup is off the charts. If you thought memorizing terrible inconsistent git commands was bad enough, this just cranks it to 11