[HN Gopher] Email and Git = <3
___________________________________________________________________
Email and Git = <3
Author : pmarin
Score : 247 points
Date : 2023-10-12 09:16 UTC (11 hours ago)
(HTM) web link (git-send-email.io)
(TXT) w3m dump (git-send-email.io)
| vimsee wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| > 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 wrote:
| correct. Opening a PR triggers an email. No difference at
| all.
| keepamovin wrote:
| :) 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
| dewey wrote:
| 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 wrote:
| GitHub has a CLI
| https://cli.github.com/manual/gh_pr_create
| dewey wrote:
| 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.
| dnsmichi wrote:
| Thanks for sharing. GitLab team member here.
|
| More GitLab push options are documented in
| https://docs.gitlab.com/ee/user/project/push_options.html
|
| You can also add a parameter to merge the merge request
| when the pipeline succeeds. This can be handy for quick
| fixes that do not require reviews, and avoids unnecessary
| context switches.
|
| # mwps BRANCHNAME
|
| alias mwps='git push -u origin -o merge_request.create -o
| merge_request.target=main -o
| merge_request.merge_when_pipeline_succeeds'
|
| Example from https://gitlab.com/sytses/dotfiles/-/blob/ma
| ster/git/aliases... and
| https://about.gitlab.com/blog/2021/10/19/top-10-gitlab-
| hacks...
|
| If you prefer deeper CLI integration, suggest installing
| the GitLab CLI:
| https://docs.gitlab.com/ee/editor_extensions/gitlab_cli/
| yankput wrote:
| 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.
| bitofhope wrote:
| This site seems to be made by Drew DeVault who also runs
| sourcehut.
| junon wrote:
| 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 wrote:
| 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."
| fsociety wrote:
| > ... GitHub forces you to be a slave of Microsoft ...
| Relax, the hyperbole is out of control here. I use GitHub
| and am certainly not a slave.
| NoGravitas wrote:
| This is honestly the best analogy.
| junon wrote:
| I really don't disagree with you at all. I also don't
| like GitHub anymore nor have I ever liked Microsoft (see
| my last few comments on HN on recent threads, in fact).
|
| I don't blame anyone for using it either, just didn't fit
| my personal workflow like mouse-based doesn't fit yours.
| keepamovin wrote:
| I think the value of alternate communication systems is
| not to be underestimated. And bravo for recalling the
| heartfelt connection between personal freedom and hacker
| culture! You are certainly "walking the walk!" :)
| Semaphor wrote:
| I contributed to a project using this, once. I decided that
| unless I'm highly invested, it's just not worth the hassle.
| terminalcommand wrote:
| 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 wrote:
| E.g. GCC does it by mail.
| keepamovin wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| AFAICT projects like OpenBSD still use the same infra:
| emailed patches and CVS (!).
| keepamovin wrote:
| 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 wrote:
| 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 wrote:
| 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 :)
| nine_k wrote:
| If you decide to expand your horizons, take a look not
| only at the venerable CVS but also at things like
| perforce, fossil, and pijul.
| mikemcquaid wrote:
| 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 wrote:
| > 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 wrote:
| 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 wrote:
| > 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)
| ploum wrote:
| I had the exact opposite experience.
|
| I've never managed to understand how to all those things,
| always switching between github web UI, github tools,
| command-line github. Everything was a mess.
|
| Then I left github for sourcehut and managed to read a book
| about git.
|
| It is still hard but now, everything makes so much sense.
| When I have a problem, instead of clicking everywhere and
| blindly copy/pasting results from stackoverflow, I actually
| think about my problem and what result I want to have.
|
| Yes, the upfront effort is harder. It is like learning Vim or
| Emacs. It's hard for the first few days/weeks then you get a
| lifetime of incredible benefits.
|
| (Bias/context: I'm the author of
| https://ploum.net/2023-02-22-leaving-github.html )
| keepamovin wrote:
| Ha! I love your bias disclaimer -- and you have certainly
| brought Homebrew out of the darkages (no disparagement to the
| earlier works); it's noticeably more performant lately. :)
|
| Your skepticism is understandable! GH seeks to bring this
| collab to all, but back then the skill required to even
| contribute was a barrier. But in a way that barrier was
| acceptable and useful.
|
| The people doing it were skilled. The basic level of skill
| required to even contribute was a lot. I think there's
| something to that.
|
| As a 14-year-old it was beyond me, or so I thought, but in
| truth it probably wasn't. But yep, you got me; I did not
| contribute! I was an observer, with a genuine admiration for
| the simplicity and effectiveness of that method of
| contribution. How sending something as commonplace as an
| email can have profound implications when it carries a
| valuable contrib!
|
| Indeed GH has some joy. Yet while convenient, modern tools
| might lack the intimacy and individualism of the older, more
| decentralized methods, which can avoid the immediate public
| scrutiny that GH may entail.
|
| I suppose you can consider my words an ode to the old ways,
| and an invitation to consider whether some elements of the
| past should be reintroduced in today's collaborative
| environs. This might sound whimsical (and perhaps not
| entirely accurate), but perhaps the "email method" was even
| more eco-friendly!
|
| It's not so much I think those things you list are a pain,
| just the overall "structure of collaboration and social
| organizing algorithms" (please excuse me; I'm finding this
| hard to articulate!).
|
| If don't get the vibe of my comment, I totally understand!
| It's intended to resonate with those who witnessed the
| evolution of dev practices and share my nostalgia for the
| early internet of the 90s.
|
| My memories of watching patches flying over those email lists
| are forever tied up with that whole early internet nostalgia.
| I loved that stuff. I read zines, and printed off RFCs so I
| could smuggle them to school and read them, just to "stay in
| touch" with online, even when we couldn't connect. :)
| mikemcquaid wrote:
| Thanks for the kind words!
|
| > As a 14-year-old it was beyond me, or so I thought, but
| in truth it probably wasn't.
|
| Eh, maybe it was, maybe it wasn't! I didn't do any
| meaningful open source contribution until the tail end of
| university/college.
|
| > I suppose you can consider my words an ode to the old
| ways, and an invitation to consider whether some elements
| of the past should be reintroduced in today's collaborative
| environs.
|
| A great idea and always worth considering <3
| bombcar wrote:
| One thing I've noticed is that the people who "live in their
| email client" (and this applies to Outlook and to using emacs
| to read email) are _very_ productive if everything is working
| right. I've seen people blow through a number of patches and
| discussions in their email client faster than I can even get
| GitHub to load the notifications.
|
| And then there's a philosophical discussion if burning
| newbie's time or discouraging them is worth making the old
| guard's time more productive- including discouraging
| interactions entirely.
|
| (This is why for certain projects you can be entirely useful
| even if you can't code; just as an intermediary)
| keepamovin wrote:
| I think the focus of attention that this workflow offers
| certainly has its advantages. There's likely a variety of
| factors at play, however!
| nunez wrote:
| When you treat your inbox as a work queue and aim for zero,
| it's easy to be productive from within your inbox
| Hackbraten wrote:
| > This is why for certain projects you can be entirely
| useful even if you can't code; just as an intermediary
|
| Argitrage?
| mikemcquaid wrote:
| I live in my email client and only use GitHub's email
| notifications. When I was working at GitHub and watching
| Homebrew/homebrew-core: I would regularly get >1000 a day.
|
| I still do not miss the days of doing patch management from
| my email client :)
| pxc wrote:
| > You think merging/rebasing/resolving conflicts is a pain
| now? Doing the same thing via email was _so_ much worse.
|
| Wait, are people doing this via the GitHub web UI these days?
| That sounds like a nightmare.
| mikemcquaid wrote:
| You can do some of this through the GitHub web UI and
| sometimes I do that.
|
| I didn't say that, though, so I'm not sure where you're
| coming from here.
| pxc wrote:
| Ah, so it's more about having a git remote to run `git
| pull` or `git rebase` against than the forge-specific
| stuff.
| js2 wrote:
| I've been contributing to open source projects since the late
| 90s. I never found the mailing list workflow awful. I also
| don't find merging/rebasing/resolving conflicts to be much of
| an issue, and I say this as someone who spent a couple years
| keeping my company's fork of Chromium rebased on-top of
| Chromium. Okay, that was a bit of a pain, especially when a
| new engineer joined Chromium and decided they just had to
| refactor an entire subsystem.
| manojlds wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| Makes sense, objectively it's also the worst OS.
| kawzeg wrote:
| If the whole list was sorted last, then first, "Alpine
| Linux" wouldn't appear first.
| dustfinger wrote:
| You are right. Thank you for pointing that out.
| vibhas777 wrote:
| The author of the website not only made this tutorial but also
| ranked the OS's according to his preference too!
|
| Windows deserves being at the bottom
| Semaphor wrote:
| Shown to HN on April 2019:
| https://news.ycombinator.com/item?id=19574257
| shmichael wrote:
| 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 wrote:
| That is a pain, but the --update-refs argument to git-rebase
| helps somewhat: https://git-scm.com/docs/git-
| rebase#Documentation/git-rebase...
| BaculumMeumEst wrote:
| 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 wrote:
| 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 wrote:
| "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 wrote:
| I would say that github is designed for those who hope to
| land a job at a Gafam by putting the number of their
| "github stars" on their resume.
| sneak wrote:
| 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.
| earthboundkid wrote:
| I think GitHub was designed for getting work done, but
| since Microsoft bought them, they are slowly moving into
| enshitification territory. For example, they have a
| homepage that is just a wanna be social media feed and
| the file contents pages have ads for Copilot and in
| general there are ads for VSCode and blah blah. It was
| pretty good, but it's going to get much worse. :-)
| BaculumMeumEst wrote:
| I disagree on enshittification. The only practical change
| I've noticed in github usage is the improvements to code
| search, which has been unbelievably useful. It gives me
| the ability to do complex searches to find real usages of
| even the most obscure libraries, examples of poorly
| documented configuration files, and more, from any public
| repository hosted anywhere on github.
|
| That capability comes from both the large body of source
| code available to the platform, and the large amount of
| engineering work put into that particular feature. It is
| one of many usability benefits is not available anywhere
| else.
| earthboundkid wrote:
| The new code search stuff is very good, yes.
|
| "Enshitification" is rapidly becoming a meaningless term
| of disapproval, but it had a precise definition when
| Doctorow coined it:
|
| > This is enshittification: surpluses are first directed
| to users; then, once they're locked in, surpluses go to
| suppliers; then once _they 're_ locked in, the surplus is
| handed to shareholders and the platform becomes a useless
| pile of shit.
|
| GitHub directed a huge surplus to developers compared to
| what came before it. Microsoft bought it and worked on
| furthering the lock in with Actions, and now the ship is
| slowly moving towards wringing the extra value out of us.
| It's not at the bottom of the hill yet, but it's
| definitely on the slope. They already have ads for
| themselves on it. The ads are just going to slowly creep
| outwards as necessary to produce a smooth revenue curve.
| follower wrote:
| > improvements to code search
|
| The enshittification related to this feature includes:
|
| (1) Code search is no longer available without being
| logged in to GitHub--even if the search is restricted to
| a single repository.
|
| (2) This is compounded by GitHub "recently" started
| requiring additional steps in the authentication process
| for certain types of accounts without providing any
| option to opt-out (e.g. by choosing to restrict the
| account to being read-only/search-only/issue-only going
| forward).
|
| There is no dialogue, you accept whatever new
| restrictions/requirements are put in place or you lose
| access to the account which you were "convinced" to use
| to contribute & interact with FLOSS projects over the
| past N years.
|
| (What other choice do you have? Convincing every single
| FLOSS project to move from GitHub to...? Good luck!)
| boredtofears wrote:
| I agree that there has been some enshitification (like
| awards, which I immediately turned off) but I like the
| activity feed.
|
| If I follow a developer, it's because I'm interested in
| what they're working on, and often I'll be exposed to
| something new in a different language or solving a
| different problem that I haven't ever tried. I actually
| think its one of the cooler things that is fairly unique
| to github.
| 418tpot wrote:
| Some of the largest and most important software is
| developed over email, e.g. Linux, QEMU, Firefox, etc...
| Don't make the mistake thinking that email doesn't scale.
| In fact, for most teams, the opposite is true.
| bitcharmer wrote:
| This is like saying that pyramids were constructed
| without modern cranes and bulldozers so obviously it's
| the right way to build stuff today. It's clearly not true
| but there are many power-wielding individuals in these
| projects who prefer to browse the web with lynx or
| develop in emacs and will impose this on anyone that
| would like to participate.
|
| This is wrong.
| r053bud wrote:
| No one is forcing you to contribute to, or even use,
| software that uses an email-based workflow. I'd also put
| money on the fact that the majority of contributors to
| Linux, an extremely successful free software project,
| prefer the email-based workflow.
| bitcharmer wrote:
| > No one is forcing you to contribute
|
| This is exactly the problematic attitude. I'm an OpenJDK
| author but not linux kernel contributor for mainly this
| reason. There are many people like me.
|
| > majority of contributors to Linux, an extremely
| successful free software project, prefer the email-based
| workflow
|
| This reminds me the many absurd conversations I had from
| my time in Goldman Sachs, few years ago. People with 15+
| year tenures claiming Slang is the best answer to any-
| and everything. They just didn't know any better and
| stubbornly stuck to tooling and mindset straight out of
| 1995.
| necrotic_comp wrote:
| Not to derail the conversation, but Slang is incredible.
| Its interface is old and archaic, sure, but it's the best
| and most expressive coding experience I've ever had. It
| took some getting used to (especially case-insensitive
| variables with spaces ?! and the UFOs) but I _really_
| enjoyed working in it. All of the other workflow tools,
| like Procmon, were icing on the cake.
|
| The internal cloud was just getting up to speed when I
| left, and that was more modern and also a joy to use.
|
| There's a lot to dislike about working there, but in my
| experience, the firmwide tooling was excellent.
| yjftsjthsd-h wrote:
| > 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.
|
| You cannot possibly claim that the other side needs to cite
| their sources and then throw numbers like that out without
| any backing.
| pjerem wrote:
| I have no great love for GitHub, I avoid it for my own
| projects but their official cli client is pretty functional
| and there are just tons of other clients, graphical or not
| for GitHub, GitLab etc ...
|
| I say that as someone who don't like GitHub, but overall it's
| far from the worst tool an employer may impose to its
| employees.
| fodkodrasz wrote:
| In case of GitHub you have this for example :
| https://cli.github.com/
|
| It is often used in GitHub CI workflows.
| raincole wrote:
| GUI is fake-usability now?
|
| Fake Edit: Oh this is HN. Never mind then.
| BaculumMeumEst wrote:
| Isn't it weird that such people bother installing a
| windowing system at all? Just work off the login terminal
| bro, it's perfection.
| howenterprisey wrote:
| What on earth is "fake-usability"? It's more usable, just
| admit it.
| BaculumMeumEst wrote:
| Fake-usability is when 97/100 software developers find
| something more usable, but it's fake because I've invested
| a lot of time doing it a different way and gotten used to
| it.
| keepamovin wrote:
| This is well said and insightful! I will reflect on this kind
| of phenomena and suspect I will be able to see it in the
| world going forward. Awareness of this will be useful to
| avoid the pitfalls described here. Thank you for making this
| contribution! :)
|
| I funnily think that many of the people poo-pooing the email
| patch method here, would just as merrily join in on HN were
| it an email mailing list collection, haha! :)
| tjoff wrote:
| Why would you set it up more than once?
|
| Copy the config, or better yet, version control it (or any of
| the other solutions to this problem).
| emptysongglass wrote:
| It really kills the fun when contributing to any FOSS project
| that fetishizes these tools and holds them up as some kind of
| proof of hacker cred. I've given up. The latency is too high
| and the tools are terrible.
| oefrha wrote:
| "Want to contribute? Subscribe to our mailing list that sends
| a hundred emails a day." Nope.
| catern wrote:
| You don't have to subscribe to send a patch to a mailing
| list.
| sjamaan wrote:
| Presumably you'd be interested in any feedback, and not
| everyone CCs the original author in their reply.
| nolist_policy wrote:
| Reply-to-all is the standard policy on most mailing
| lists. Especially on -devel lists since you'll pull in
| (CC:) people outside of the mailing list (cross-project)
| into discussions from time to time.
| Avamander wrote:
| I know more than one occasion where that has gotten an
| angry reply.
|
| It's also not the default in many clients. It's tedious
| and error-prone.
| oefrha wrote:
| I have more than once subscribed just to report a bug or
| send a patch because the mailing list rejects emails from
| non-subscribers.
|
| Edit: Btw, yes I have done the periodically-check-archive
| thing in the past, thank you. Hated it. Also missed a
| response once because I forgot to check and replier
| didn't CC. I realized like a month later.
| Hackbraten wrote:
| Even then, you're free to opt into daily digests if
| you're a subscriber. The message ID allows you to reply
| to individual messages and threads nonetheless.
| catern wrote:
| It is unfortunate that there are poorly-managed projects
| with poorly-managed mailing lists (just like there are
| poorly-managed projects on Github), but sourcehut at
| least requires a properly-managed mailing list, and I
| think you should evaluate this workflow on that standard.
| Tell poorly-managed projects to move to sourcehut, if you
| want to fix this issue.
| severus_snape wrote:
| You don't need to subscribe. You are in CC when people want
| you to be notified, otherwise there are web interfaces you
| can browse. See https://lists.gnu.org/archive/html/guix-
| devel/ for example. On each message there is a button:
| "reply via email to [...]".
| emptysongglass wrote:
| This interface is awful. I wish GNU would make more of an
| effort to be easy to contribute to.
| severus_snape wrote:
| I usually know, when the interface is not too shiny, that
| the content might be good. It's the same with HN. And
| those interfaces are still very easy to understand and
| use.
|
| That being said, there is certainly room for improvement.
| tmpX7dMeXU wrote:
| No. It tells you that the community is an ever-
| diminishing echo chamber full of your "hacker" tool
| fetishist mates. Anyone that perpetuates the ongoing use
| of these rubbish tools and workflows is just saying that
| appeasing their mailing list fetish is worth it all
| likelihood decimating the community's active contributors
| over the next 5-10 years as, to be blunt, these people
| continue to retire and/or die with nobody to replace
| them.
| rpdillon wrote:
| There's something to this idea, I think. The less
| polished a tool is, the more I'm inclined to think it was
| built by the community for community use. There's so much
| talk about enshitification, and I'm struggling to recall
| when a tool with a less-than-polished interface had that
| problem.
|
| The example that springs to mind is spamgourmet, which
| has a FAQ about why they don't redesign their site. I've
| used the service for about 20 years, and while there is a
| bit of a gatekeeping vibe to it, there is also a good
| reason: they have very few resources for support, and
| want to attract a certain crowd to minimize the support
| burden. It seems it's been working for a couple of
| decades, at least.
|
| > Q. Couldn't you make the whole thing a lot easier to
| understand by redesigning your site and providing
| instructions in a more clear way?
|
| > A. Probably. Frankly, we're trying to build a user base
| of people like you, who probably have some familiarity
| with the way email works and who are willing to read
| FAQ's. This is to keep our support burden to a minimum
| (this is a non-commercial service). So far, the approach
| has worked well -- just about all our users hit the
| ground running with no need for support, and it's our
| belief that those users who would require support
| generally don't sign up in the first place, perhaps
| because of the geeky presentation of the site. That's not
| to say we don't provide support where it's needed --
| after skimming this FAQ, please don't hesitate to write
| if you have a question or believe there's a bug.
|
| https://www.spamgourmet.com/index.pl?printpage=faq.html
|
| I tend to actively seek out projects like this, since I
| don't mind the blow to usability, and very much
| appreciate that they provide the service and don't pepper
| me with annoucements about their new improvements or
| their changes to their pricing structure.
| brettermeier wrote:
| Damn, this is ugly and confusing, I mean, look at the
| threads XD! I'm glad I must not use this shit.
| IshKebab wrote:
| Shh now. A basic interface that took 5 minutes to make in
| 1995 is good enough for all eternity. No need to change
| it.
| oefrha wrote:
| I certainly love navigating a million times back and
| force to read what should be a single thread.
| Avamander wrote:
| I also love all the "new" threads generated by mail
| gateways changing the subject to something the likes of
| "Re: [EXTERNAL SENDER!] Re: Topic"
| fodkodrasz wrote:
| Subscribe to our mailing list, where we are rude and
| dismissive if you accidentally dare make a line longer than
| 50 characters, (didn't you read our netiquette?) as some
| members like to read their emails on outdated devices
| without text reflow capable display software. Also don't
| dare to use non-ASCII Unicode characters, or we will be
| rude and will ignore your request. Just spell your name in
| American, because that is what real programmers do!
| BaculumMeumEst wrote:
| Even better is when people post issues on Reddit or
| whatever asking for help because that's the most low
| friction way for them to ask, and then a project
| contributor replies with "hey can you send this to the
| mailing list?" and so the person sends it in and is met
| with exactly fucking this. It's just such a great use of
| everyone's time.
| severus_snape wrote:
| # do your code change git commit git send-email
| --to=<some mailing list> -1 # amend your change
| git commit --amend git send-email -v2 --to=<some mailing
| list> -1
|
| I'm not sure what is needlessly annoying and absurd.
|
| Edit with minimal configuration: cat
| ~/.gitconfig [user] email = your@mail.address
| name = Your Name [sendemail] smtpuser =
| your@mail.address smtpserver = smtp.whatever.com
| smtpserverport = 587 smtpencryption = tls
| MaxBarraclough wrote:
| They said they found it difficult to _configure_ , not that
| they found it difficult to use afterwards.
| tlamponi wrote:
| If your system cannot relay mail correctly already, as most
| office setups are easy to configure to be able to provide
| that without extra config, at least for Linux setups, then
| the set up means having something like the following in
| their gitconfig: cat .gitconfig #
| snip [sendemail] to =
| default@list.example.com annotate = yes
| suppresscc = self smtpencryption=tls
| smtpserver=imap.example.com smtpserverport=587
| smtpuser=foo.bar@example.com
|
| (only the ones starting with "smtp" are relevant for mail,
| the other ones are just there for convenience)
|
| And that has to be done _once_ , iow., in essence it's as
| hard a setting up an email fat client like thunderbird.
| earthboundkid wrote:
| FWIW, I haven't done that kind of setup for years because
| modern iOS/macOS does email server discovery, where you
| enter "bob@example.com" and then it does discovery and
| figures out the right imap.example.com:587 etc for you by
| looking at DNS.
| oefrha wrote:
| You left out the entire configure SMTP step. Honestly I'm not
| even sure how to do that if your SMTP server requires 2FA and
| does not allow legacy app specific passwords.
| tlamponi wrote:
| Every mail server/provider that provides 2FA that I used
| allows for configuring "tokens" (called a bit different
| everywhere) which are a high entropy random string, and
| some of them require TFA only for IMAP or POP, i.e.,
| getting mail, not SMTP, i.e., sending mail.
| rascul wrote:
| There are instructions provided for Gmail and some others:
|
| https://git-send-email.io/#step-2
|
| A tool from Google is mentioned and linked to:
|
| https://github.com/google/gmail-
| oauth2-tools/tree/master/go/...
| oefrha wrote:
| That uses app specific passwords, and with Google
| Workspace, the administrator can completely turn off
| these "less secure apps". Pretty sure Office 365 has the
| same.
| bombcar wrote:
| There's another method that doesn't use app specific
| passwords but I'm not entirely sure how it DOES work - it
| opens a connection and then gives you a web address to go
| to in your browser to authenticate with 2fa. And then
| somehow it magically works until it decides it doesn't
| like you anymore.
| oefrha wrote:
| I never studied the protocol of Gmail/Exchange/etc. 2FA,
| but I suppose the SMTP auth token expires after a while,
| and the client somehow hasn't implemented token refresh?
| Anyway, glad to know there is a way (?) to get git-send-
| email working with stricter 2FA.
| bombcar wrote:
| I've always assumed that the server side stores as much
| information about the client as it can, so not just
| "username/password" but source IP, client headers, etc
| and somehow uses that as a "session token".
| rascul wrote:
| The tool from Google that is linked to appears to use
| oauth2.
| trws wrote:
| Sadly you're right. Microsoft has brainwashed many IT
| departments into forcing oauth on everything, no app
| specific passwords, no regular passwords, nothing else.
| Thankfully they do support this on imap and smtp, but you
| have to have something that can handle it. I use a
| modified version of isync with the sasl plugin to fetch
| mail, and a python smtp sender that supports the oauth
| flow along with a set of scripts for generating a new
| refresh token every few months. It's a heck of a lot of
| stuff to maintain, but at least it works. If anyone's
| interested I could provide links or upload the modified
| versions to fix o365 quirks.
| andris9 wrote:
| Multiple enterprise customers use my software
| (https://emailengine.app) because it can proxy
| OAuth2-enabled IMAP/SMTP connections as regular password-
| based sessions. Turns out there are a lot of legacy, like
| all kinds of cron scripts, that want to connect to some
| IMAP account to check and do something. It all breaks
| down once the organisation enforces OAuth for their
| email. So, personally, I don't like it at all, but as a
| software developer, I'm really happy about it. Helps with
| my sales effort :P
| trws wrote:
| Oh that's pretty cool, thanks for the link. I've used
| davmail as a proxy like this, just for the oauth support,
| but it doesn't scale to large mailboxes or high traffic
| well at all. May forward this along for some of our
| internal services people.
| tlamponi wrote:
| Configuring git send-email is trivial, definitively faster than
| creating an account at some web UI from a "source forge" - it's
| literally setting a handful of properties in the `.gitconfig` -
| and those are not specific to a project, but just your mail
| server settings you can reuse them for any project that accept
| patches over mailing lists.
|
| And using it for a project that accepts this workflow is such a
| joy, no need to figure out weird merge request that make me re-
| enter all the information I had in my git commits already.
|
| If it's only a few patches, say three, I can do a simple `git
| send-email --to mailing@list.example.com -3`, maybe throw in
| `--cover-letter` for some meta info if the changes are even big
| enough to require that, and be done.
|
| Certainly to each their own workflow, and once can get
| accustomed to a lot of needless tasks and workflows, but how
| one can look at the bloated interfaces that try hard to add
| vendor-lock-in and say "this is so much simpler and easier to
| grasp" can IMO only mean they never tried this way in good
| faith. In the end sending a mail is trivial, and code changes
| are text (most of the time), it can hardly be beat in
| simplicity.
|
| Anecdotally, most of our new hires from the last years had no
| experience with the email workflow, and a few weeks in most of
| them find it way better, while the rest finds it at least as
| good as the alternatives (and here they mean gitea or
| sourcehut, not the monsters that GitHub/Lab are).
| ligurio wrote:
| > Configuring git send-email is trivial, definitively faster
| than creating an account at some web UI from a "source forge"
| <snipped>.
|
| You forgot that mailing list requires subscription and in
| some cases it could be a tricky. Without proper subscriptions
| and confirming subscription, your mails with patches will go
| to trash.
| severus_snape wrote:
| There is usually no need to subscribe.
| nolist_policy wrote:
| This. You just To: the mailing-list and depending on the
| project CC: the maintainers.
|
| No subscribing needed. Standard policy on all mailing
| lists is to reply-to-all so you'll get always CC'ed on
| replies. This also makes it very easy to pull in more
| people into a discussion, even across different projects.
| kazinator wrote:
| That's how mailing lists _should_ work.
|
| Many mailing lists today reject posts from non-
| subscribers.
|
| Of those that allow posts from non-subscribers, you will
| find that many are configured such that you will not get
| a reply, due to "reply-to munging". Your message will go
| to the list, but with a Reply-to: header designating that
| list, instead of (or in addition to) setting the more
| modern mailing-list-related headers.
|
| Reply-to-all isn't a list policy; it's a behavior of the
| individuals. Some people don't reply to all. They think
| they are, but only the post author gets their reply. That
| is one of the motivations behind the Reply-to.
|
| https://marc.merlins.org/netrants/reply-to-still-
| harmful.htm...
| diggan wrote:
| In what cases is it tricky? I find that most projects use
| some version of mailman (like QEMU -
| https://lists.nongnu.org/mailman/listinfo/qemu-trivial) and
| then it's just a question of filling out the form and
| hitting "Subscribe". I cannot remember project I wanted to
| contribute to, I had to use git+email and it was difficult
| to subscribe to the mailing list they want me to use.
| stefan_ wrote:
| And then every so often mailman hits you up with "I'm
| receiving all these bounces from your email server!"
| because all the various garbage anti-spam techniques were
| not quite thought out with mailing lists in mind or
| people have lots of misconfigured servers and servers
| with different acceptance criteria, and it's all a big
| mess.
|
| Configuring git send-email is only half the battle,
| anyway - chances are you want to participate in the
| discussion of your patch, so better figure out how to
| make sure your email client will not send the forbidden
| HTML email.
| bbarnett wrote:
| That's a _battle_??
|
| This sounds like hyperbolic brought on by dislike, not a
| real indicator of time cost/effort. You've already spent
| more time complaining, than the work done to do these
| things!
| IshKebab wrote:
| How is that harder than signing up to Github?
| zanecodes wrote:
| I only have to sign up to Github once, not once per
| project.
| diggan wrote:
| Personally, it's not. I'm using GitHub and I also
| sometimes send patches in emails.
|
| I'm asking specifically what part of subscribing to
| mailing lists is the tricky part, as that's what parent
| mentioned. I'm not saying it's easier/harder than
| GitHub's workflow.
| wodenokoto wrote:
| I think you meant "how is signing up for GitHub harder
| than that?"
| jorvi wrote:
| > not the monsters that GitHub/Lab
|
| You mean cloning a repo and then simply pushing upstream?
|
| I can't fathom how anyone would think that is more
| complicated than e-mail push workflows.
|
| It's like someone telling you that IRC is "obviously" less
| complicated than setting up a Discord account.
| severus_snape wrote:
| For most channels you don't need an IRC account. And there
| are web interfaces like https://web.libera.chat/.
|
| I'm trying to subscribe to Discord. I'm currently stuck in
| a captcha loop.
| pxc wrote:
| 100%.
|
| Clicking a link to open a chatroom directly, with no
| account creation process, is infinitely simpler than
| account creation, potentially with several layers of
| verification (CAPTCHA, email, phone verification to join
| a server...).
| notpachet wrote:
| There's complexity and then there's complexity. Your end
| user experience as a Discord user may be simpler on its
| face, but it's reliant on a lot of obfuscated complexity
| under the hood. You wouldn't be able to, say, send Discord
| messages using telnet, the way you can with IRC. Discord's
| simplicity in setting up an account, joining servers,
| having scrollback, etc comes at the cost of other types of
| simplicity.
|
| People in this thread are talking past each other without
| realizing that they are expressing different preferences
| about where complexity belongs in a tool.
|
| (For the record, I happen to be on the IRC / git mailing
| list side of the spectrum.)
| LudwigNagasena wrote:
| "Obfuscated complexity" aka good UX that decreases
| friction and increases velocity.
| notpachet wrote:
| Again, friction and velocity of what? It's a lot easier
| for me to write an IRC bot than a Discord bot. But other
| things are much harder to do with IRC. People are looking
| at different vectors.
| BaculumMeumEst wrote:
| your parens enclose the most unneeded addendum i have
| ever seen
| notpachet wrote:
| That's surely hyperbole. You can just say "This is
| unnecessary" and it achieves the same purpose. Maximalist
| comments like this tend to amplify the tension in these
| sorts of discussions.
| BaculumMeumEst wrote:
| yes it is hyperbole
| rakoo wrote:
| You mean
|
| - cloning the repo in github to your own fork
|
| - cloning your fork locally
|
| - pushing to your local fork after you've made your change
|
| - opening a PR
|
| Which is the expected flow for any project you're not
| already part of, ie all of them.
|
| The email workflow:
|
| - send an email
|
| I can't fathom how you can say the email workflow is more
| complicated.
| bastardoperator wrote:
| I have absolutely no desire to send all of my companies
| intellectual property to a mail server. It could be the best
| workflow in the world, but if one email address gets
| breached, you're leaking everything and that's really
| unacceptable.
| delusional wrote:
| Isn't this also the case for centralized git servers? Even
| moreover if you run a monorepo.
| bastardoperator wrote:
| No clue, I prefer to use a monster that actually has
| security mechanisms, and protocols in place designed by
| professionals.
| yjftsjthsd-h wrote:
| > I prefer to use a monster that actually has security
| mechanisms, and protocols in place designed by
| professionals.
|
| Like a mail server?
| bastardoperator wrote:
| I don't know, sending sensitive information over plain
| text doesn't scream security to me. So no, unlike a mail
| server.
| yjftsjthsd-h wrote:
| It's 2023; mail servers have been using TLS for a very
| long time.
| bastardoperator wrote:
| Yes, you can transmit messages via SMTP using TLS, but
| you don't need any special tools to read the email once
| it's reached its destination which is the point you seem
| to be missing. And before you scream PGP, almost nobody
| uses it.
| yjftsjthsd-h wrote:
| But that's exactly the same as anything else; you move
| git commits that you store locally (either encrypted or
| not) over an connection that's encrypted in transit
| (whether SMTP/TLS, HTTP/TLS, or git/SSH) to a remote
| server that stores the repo/commits (either encrypted or
| not). None of this is different depending on whether the
| remote is a mail server or github (or whatever).
| pietro72ohboy wrote:
| TLS secures your message till the endpoint which is a
| (plaintext) code repo. Why would you want a special tool
| to read plaintext code? Your argument makes no sense
| whatsoever.
|
| I'm not sure what you're getting at here but it sounds
| more like an irrational hatred of email than something
| genuinely technical to me.
| rakoo wrote:
| So, like a centralized git server ?
| Galanwe wrote:
| No thank you.
|
| Avoiding email based workflows and alerting is one of my top
| priority in every job I have had.
| mvdtnz wrote:
| > Configuring git send-email is trivial
|
| The linked article is literally a multi-step process of
| arcane terminal commands that differ by operating system. You
| may think it's easy, but it's definitionally not trivial.
| silverfox17 wrote:
| 'Arcane terminal commands'? These are standard basic
| terminal commands.
| felurx wrote:
| The thing that differs by OS is the installation of Git.
| nicoco wrote:
| It's also possible to not be religious about it. Git is
| distributed. I have projects on srht and contributing does not
| mandate using the send-email workflow. "Push it somewhere and
| let me know where I can pull" always works too.
| TotempaaltJ wrote:
| Hard agree! I think the success of Github's PR system over Git
| + email workflows has proved itself quite well through sheer
| adoption numbers.
| tristan957 wrote:
| The largest open-source software projects in the world don't
| use it though, so that tells me there is something lacking.
| bitcharmer wrote:
| Maybe so, but my interpretation is that there's personal
| opposition to change and improvement from people like Linus
| or TGLX or other greybeards. At least in the linux kernel
| world. The contribution by email is an antiquated approach
| and needs to go.
|
| Now, knowing the HN crowd this comment will become grey in
| 3... 2... 1...
| ungamedplayer wrote:
| They say that scientific discovery advanced one death at
| a time. I imagine this same theory applies to kernel
| development tooling.
|
| I understand not changing for change sake. The kernel is
| at this time not "this gen" developer friendly.
| tristan957 wrote:
| What is antiquated about sending patches via email? Have
| you ever used email to contribute to a project or review
| a patch?
| djha-skin wrote:
| > not only drive away a significant number of potential
| contributors,
|
| It drives away the kind of people who have little patience for
| technology problems and little patience for learning new
| things.
|
| I don't want those kind of people working on e.g. Git. Git
| needs people who have lots of patience for technology problems
| and lots of patience for learning new things.
| tmpX7dMeXU wrote:
| Oh please. Lots of people, myself included, take issue with
| having to answer your riddles three before I may cross the
| bridge that you value much more than I do.
|
| There's having patience and problem-solving ability, and
| there's not seeing the value in jumping through the various
| hoops that comprise some '90s Internet fetishist's
| playground.
|
| This is all just code for "I'm old, set in my ways, and don't
| appreciate the fact that the only reason I find my workflow
| easier is because I know it, not because it's more intuitive
| than what people are doing these days".
| fodkodrasz wrote:
| > It drives away the kind of people who have little patience
| for technology problems and little patience for learning new
| things.
|
| like learning to use a GUI and a Web Interface?
| scbrg wrote:
| It's not really that people _can 't_ use them. It's that
| they're slow, annoying, hard/impossible to automate,
| hard/impossible to customize and give you RSI.
|
| We've seen Web interfaces, they're hard to avoid. We've
| just decided that they're worse.
| fodkodrasz wrote:
| Could you, for a moment, imagine that others might feel
| like that about the command-line-plain-text-email-to-
| mailing-list workflows? Possibly not, as you have
| labelled them
|
| > the kind of people who have little patience for
| technology problems and little patience for learning new
| things
|
| Also tell me how is tolerating rude incumbents of mailing
| list sending email with 50+ characters in a line a
| technical problem? (Yes they are often rude, and
| unwelcoming to those attempting to accept their
| anachronistic ways. You are demonstrating that specific
| behaviour right here, which many of us have encountered
| on those projects.)
|
| I think the projects which accept contributions only from
| mailing lists will have their contributors die out, or
| will be forced to change their ways to survive. I for one
| will never again attempt to contribute to such project,
| thanks to the inflexibility of the incumbents I have
| faced several times. Also thanks to the sub-par review
| workflow, usually the lacking quick CI feedback.
|
| Web UI might give you RSI, but the insufferable email-
| only-patches people give me PTSD from my previous
| encounters.
|
| ps: if you are _willing to learn new things_ , you can
| automate web apps and GUI apps (eg. Autoit, xaut). Some
| even have proper APIs (COM/dbus/web api), or a cli!
| bitcharmer wrote:
| No, it drives away people who don't want to develop in vim or
| emacs and prefer to use modern tools instead.
| softirq wrote:
| What isn't modern about neovim or emacs 29? Does a tool
| have to be graphical to be modern?
| sbjs wrote:
| There's a psychological basis for people taking pride in a
| difficult task learned and mastered, and many organizations
| take advantage of this by creating a culture that rewards this
| effort when put towards their own products with social status
| within the organization. It feels manipulative and unethical to
| me.
| sbjs wrote:
| (Dare I say HN is one of them, where the effort is a curated
| form of elitism, and the mechanism up/down votes?)
| carapace wrote:
| Like GitHub.
| gwd wrote:
| Our project inherited a patchbomb-based workflow from Linux.
| Many of the individual members have also contributed to
| gitlab/hub based projects, and appreciated a lot of the
| automation available, as well as recognizing the lower barrier-
| to-entry of not having to figure out how to get an SMTP
| connection. So a few years ago we experimented with allowing
| "small" patches to be sent via PR on gitlab, and doing the
| review there.
|
| Basically, everyone agreed that actually doing the review on
| gitlab was a lot worse compared to email. There's just so much
| more flexibility.
|
| It's not off the table that we may give it a try again, because
| the advantages of having concrete pull requests (and issues
| and...) rather than patch series is pretty significant. But if
| you're familiar with doing email-based review, I think it's
| still a far superior; and you're definitely giving something up
| when you move away from it.
| 0xffff2 wrote:
| >Basically, everyone agreed that actually doing the review on
| gitlab was a lot worse compared to email. There's just so
| much more flexibility.
|
| Could you elaborate? This is truly shocking to me. Admittedly
| I have never worked on a project with an email-based
| workflow, but I can't think of how email would allow comments
| inline with the patch, which is an incredibly beneficial
| feature to me.
| gwd wrote:
| Well yeah, replying in-line to the patch to make comments
| is definitely a requirement. :-)
|
| You always reply with quotes; and you always reply inline,
| below the thing you're replying to. Quoted material is
| typically indicated by '>'.
|
| So for one thing, you can easily trim your reply to just
| the bits of the patch that you think is important; that
| makes it easy for anyone reading; you don't have to skip
| over large parts of the thread.
|
| Then you can also re-arrange what you're replying to, to
| make it make your reply make more sense.
|
| Furthermore, suppose A replies to the patch and makes
| comments 1, 2, and 3 (inline in a single email). When
| person B replies to A's email, they typically also send a
| single email, perhaps with replies 1' and 3' (trimming out
| comment 2, which they don't care about). This means if
| you've read A's mail, you can just read B's mail, and all
| the "new" comments are collected in one place (with the
| thing they're replying to).
|
| Contrast the above with gitlab, where A's replies 1, 2, and
| 3 are spread throughout the patch; and B's replies will
| also be spread out, meaning you have a kind of
| discoverability problem to see both 1' and 3'.
|
| And suppose in the course of talking about something you
| realize this bug may actually be a security issue -- you
| can remove the list, cc' "security@", and pick up the
| discussion without having to do any copy & paste. Same goes
| if you want to make a private comment, or bring something
| to someone's attention; just reply, remove everyone else,
| and say "FYI".
|
| I wish I had a really good recent example to show you, but
| a quick skim of today's threads isn't anything special. :-)
|
| I mean, I was arguing with people online [1] on BBS's in
| the early 90's, and I was on Usenet back when that was the
| main social network; so this "reply and comment inline" way
| of having a discussion is pretty well ingrained for me. But
| there are people on my team in their early 30's who also
| took to the email workflow really quickly too.
|
| [1] https://xkcd.com/386/
| pookha wrote:
| I like git patches...I can scan through them, write
| comments, and maybe strip out files that aren't necessary
| (if you have two isolated networks and are syncing code in
| between). I'm a fan of some of these ambitious git projects
| like GitLab but there's just something about syncing git
| through patches (like email).
| diogenes4 wrote:
| > 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
|
| You could say the same of GitHub. Why do I need an account on
| your lil site just to get a patch accepted?
| grayhatter wrote:
| > Organizations that insist on using workflows like git send-
| mail and mailing lists not only drive away a significant number
| of potential contributor
|
| Often that's a bonus if not the whole point to begin with. The
| higher the barrier to entry the less noise you need to filter
| through.
|
| It only feels annoying to you because you're not used to it.
| 0xbadcafebee wrote:
| > workflows like git send-mail and mailing lists not only drive
| away a significant number of potential contributors
|
| A GitHub PR is _way_ more steps than e-mailing a patch to a
| mailing list, and far less accessible. Have you never done the
| "sign the contributor license agreement and get the GitHub bot
| to approve it" polka? I've done it a dozen times now, it's
| painful and way more gatekeepery than just emailing a patch.
|
| > but they also form a weirdly religious culture that
| fetishizes needlessly painful process and is incapable of
| improvement
|
| Who hurt you?
| carapace wrote:
| You went from "I find it inconvenient" to "they're masochistic
| cultists" pretty quickly there. _Ad hominem_ attacks are
| against site policy.
|
| You've spawned a huge thread of people being incredibly self-
| righteous about the mind-boggling difficulty of _sending
| email_. It makes me think that it 's actually a great filter to
| keep out people who prefer drama to clicking a few buttons that
| are different than the buttons they're used to clicking.
|
| I understand that familiarity is a powerful driving force in
| human psychology, but really, it's not like it's that hard to
| learn a different flow. I mean, I've had to use _Perforce_ ,
| and while it's fun to complain, it really wasn't that hard. I
| didn't even have to get out of my chair.
| moritzwarhier wrote:
| The process tends to be a lot less painful when using git-
| combine-mailmap [1]
|
| ^1
|
| https://git-man-page-generator.lokaltog.net/#Y29tYmluZSQkbWF...
| wkz wrote:
| It's easy to forget the maintainers' side of this.
|
| Yes, most contributors will prefer opening a PR on GitHub as
| apposed to mailinglists. But imagine instead that you are David
| Miller, and it's your job to consume the absolute fire hose of
| patches and messages related to Linux's networking subsystem.
| Would you rather wade through the hundreds of messages and
| patches coming in every day using either GitHub PRs and issues
| or email?
|
| I would choose email for one simple reason: It's easier to
| script.
|
| Even as a small-time contributor and observer to that space, I
| couldn't even imagine trying to keep up with everything going
| on if I couldn't bulk download, filter, tag etc. As a
| maintainer it would be excruciating.
| jeffybefffy519 wrote:
| Github has an api for this...
| diggan wrote:
| Which eventually will change, and you have to update
| everything. Or the company disappears and you have to move
| somewhere else.
|
| Email is just email. You write SMTP/IMAP clients today and
| they'll continue to work for a long time, probably longer
| than most platforms with APIs online today.
| MatthiasPortzel wrote:
| > 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 wrote:
| The point is being able to discuss and archive things via
| email. Using a zip file makes this moot.
| tlamponi wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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.
| gwd wrote:
| 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 wrote:
| 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 wrote:
| 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.
| IsaacSchlueter wrote:
| 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 wrote:
| Email-driven contribution systems, no thanks. Why anyone would,
| in 2023, elect to use email as the backbone for their development
| processes eludes me.
| thayne wrote:
| 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 wrote:
| 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/
|
| If you're interested, see also
| 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/ [1]: 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 wrote:
| 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.
| 0xbadcafebee wrote:
| It is way faster and easier for me to just open up my email
| client, attach a patch, and send it.
| pyrolistical wrote:
| This is the fediverse they want
| darau1 wrote:
| 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
| mvdtnz wrote:
| 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 wrote:
| 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".
___________________________________________________________________
(page generated 2023-10-12 21:01 UTC)