Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Git email flow vs. GitHub flow

blog.brixit.nl

Post reply on HN
Print view View original

71–80 of 177 posts

Re: Git email flow vs. GitHub flow

#71

Post by toomanybeersies »

maeln wrote: post #55

> If your main complaint is that email is horrible to work with, the issue is most likely not email, it's probably your mail client. This is definitely talking from someone who never had to write software that deal with emails. The reality with emails ? They are an horrible format. There is several RFC describing the "email" format, the usual reference is rfc2822, but technically, you can find other rfc that relate t…

Email, in some iteration or another (starting with RFC524), not only predates the internet, but predates TCP. The only older standardised communications systems still in widespread use are the telephone and the postal systems.

It's an unfortunate quirk of how the internet has developed that email has stuck around, like postal mail, as long as you put the correct address on the outside of the envelope, you can put almost anything inside.

RFC 822 makes it clear this is a feature:

> In this context, messages are viewed as having an envelope and contents. The envelope contains whatever information is needed to accomplish transmission and delivery. The contents compose the object to be delivered to the recipient. This standard applies only to the format and some of the semantics of message contents. It contains no specification of the information in the envelope.

Re: Git email flow vs. GitHub flow

#72

Post by sofixa »

nethead wrote: post #57
sofixa wrote: post #37

Earlier quoted context omitted.

I can't imagine that crowd doing it anything but their preferred way. Remember when a Debian maintainer quit due to the obsoleteness of the toolchain that the other maintainers flat out refused improve because "it worked" ( my google-fu is failing me, if someone finds it please post it)? I imagine things to be the same with the kernel ( not saying the toolchain is obsolete, just that if it were, they won't just chang…

This one: https://michael.stapelberg.ch/posts/2019-03-10-debian-windin... ?

Yep, thanks!

Re: Git email flow vs. GitHub flow

#73

Post by sreevisakh »

600frogs wrote: post #52

The author suggests that if I find email horrible to work with, it's my mail client that's at fault, but doesn't expand as to why this is or make any suggestions for what to use - can anyone help me out here? What am I missing from some amazing holy grail mail client that I don't get in gmail webapp or the default MacOS mail app?

Conventional mail clients and web clients are a non-starter if you want to work with mailing lists or git email workflows. To begin with, both of them rely heavily on email threads. Patch sets and reviews are both threaded. Modern clients don't emphasize these threading well enough, and can leave you confused about the context of the messages when using these workflows.

Another problem is html mail. Lists and patches are easier to read as plain text. But again, it's hard in modern clients to figure out if you are composing a plain-text or html mail. As a result, you end up with mangled patches and badly formatted text in the mailing list. Another really annoying problem is top-posting when replying to a mail. Ideally, the quotes from original message and the reply should be interleaved, so that the context of the discussion is very clear. But web clients often just quote the entire original message and hide it away at the bottom of the reply. It isn't even easy to expand and split the quotes.

Finally, there is the problem of applying patches to repository from email. I don't think this was even a design consideration for modern clients.

> What am I missing from some amazing holy grail mail client

I assume you are unfamiliar with the workflow. The reality is that the UI is never ideal, even with traditional text mail clients. List support is better than with modern clients, but patches need hacks or a bunch of other tools. But the tool selection makes it way more tolerable than using web-clients or modern desktop clients. There is a lot of room for improvements and there are on-going efforts to improve the situation (like ddevault's aerc). However, you end up with the realization that mailing lists and git email workflow can be as easy and enjoyable as fork-pr workflow, once you overcome the difficulty of initial setup. Perhaps some day, we will have a text client that is trivial to setup and covers all the steps in using mailing lists and patches.

For now though, I believe that mutt is the most commonly used client for the workflow. For some other reason, I use mu4e as my client. Drew Devault's aerc looks promising in the long term. For more detailed explanation, have a look at this post by Greg Kroah-Hartman: http://www.kroah.com/log/blog/2019/08/14/patch-workflow-with... (I just discovered this today from ddevault's reply in this discussion).

Re: Git email flow vs. GitHub flow

#74

Post by swiley »

ClumsyPilot wrote: post #68
IgorPartola wrote: post #9

Earlier quoted context omitted.

The Linux kernel uses email. I can’t imagine that crowd does things the inconvenient way.

Despite technical brilliance, this is one of the most closed-minded and stubborn crowds arounds. Just look at the reaction to adding case-insensitive functionality in filesystem in comments: https://www.collabora.com/news-and-blog/blog/2020/08/27/usin...

Case insensitive filesystems are a really bad idea though.

Re: Git email flow vs. GitHub flow

#75

Post by ddevault »

nethead wrote: post #57
sofixa wrote: post #37

Earlier quoted context omitted.

I can't imagine that crowd doing it anything but their preferred way. Remember when a Debian maintainer quit due to the obsoleteness of the toolchain that the other maintainers flat out refused improve because "it worked" ( my google-fu is failing me, if someone finds it please post it)? I imagine things to be the same with the kernel ( not saying the toolchain is obsolete, just that if it were, they won't just chang…

This one: https://michael.stapelberg.ch/posts/2019-03-10-debian-windin... ?

This seems to have everything to do with Debian and nothing to do with git-via-email.

Re: Git email flow vs. GitHub flow

#76

Post by ddevault »

jillesvangurp wrote: post #48
eeZah7Ux wrote: post #47

Earlier quoted context omitted.

The email workflow is objectively, measurably simpler and it works really well for kernel development. Look at the examples on sourcehut. Yes, it takes a moment to get used to something different, but that's a human problem.

It works well for people used to command line interfaces to email, mailing lists, and using cli tools exclusively. Old people in other words. No shame in that; I am one. But I'm well aware that I'm a minority. I mostly work with twenty somethings these days. Keeps me mentally younger than I have any right to be. Also forces me to keep updating my skill sets. In any case, I tick only one of those boxes as I use a lot…

This is a really nasty argument. "Old people" are (1) not the only people who understand mailing lists, (2) not the only people who like mailing lists, and (3) not "set in their ways", so to speak, or failing to "updating their skillset". There are plenty of "twenty-somethings" which use the email workflow. What a gross, ageist comment.

>The nice innovation of the pull request by Github achieves a similar flow but with a pretty UI, easy to use tools for commenting, line by line review, search, issue tracker integration, and a bunch of other things that IMHO stopped being optional on most projects. I kind of like the traceability of PR #4 closes issue #13 and successfully cleared CI & received a positive review so it is safe to merge.

There is nothing preventing these features from being done with email, either.

>You can get a good picture of that via Githubs insights on Linus Torvalds fork of linux. I don't think he uses pull requests though. Is there an issue tracker for linux even?

I wrote an article which can offer some insight into the Linux development process:

https://drewdevault.com/2020/09/02/Linux-development-is-prof...

Re: Git email flow vs. GitHub flow

#77

Post by leephillips »

gkya wrote: post #65
rakoo wrote: post #50

I still don't understand why, for projects and similar topics-based discussion, we don't use NNTP instead of Email. Email is good for addressing specific people only, and you're supposed to have been part of the conversation since the beginning so it does apply to personal correspondence but it scales horribly bad for groups of people: - there is no included history. You need to manually download hand-crafted archive…

No "good" NNTP clients, maybe besides Gnus and slrn, which are rather obscure. Gmane was relatively popular, and it was great but went down for a long time, which probably further obscured NNTP. IDK if everyone who used to use it is aware that it's up again, now at http://gmane.io/

Those are both definitely good clients. And the idea to use NNTP is good, too, but has almost no chance of taking off, for social reasons.

Re: Git email flow vs. GitHub flow

#78

Post by IgorPartola »

ClumsyPilot wrote: post #68
IgorPartola wrote: post #9

Earlier quoted context omitted.

The Linux kernel uses email. I can’t imagine that crowd does things the inconvenient way.

Despite technical brilliance, this is one of the most closed-minded and stubborn crowds arounds. Just look at the reaction to adding case-insensitive functionality in filesystem in comments: https://www.collabora.com/news-and-blog/blog/2020/08/27/usin...

Why would you ever want a case insensitive file system?

Re: Git email flow vs. GitHub flow

#79

Post by maeln »

andrius4669 wrote: post #70
maeln wrote: post #55

> If your main complaint is that email is horrible to work with, the issue is most likely not email, it's probably your mail client. This is definitely talking from someone who never had to write software that deal with emails. The reality with emails ? They are an horrible format. There is several RFC describing the "email" format, the usual reference is rfc2822, but technically, you can find other rfc that relate t…

>RFC 20452, RFC 20463, RFC 20474, RFC 20485 >RFC 68388 what are these numbers, I don't recall RFCs going into 5 digits yet

Yes my bad, it is from a bad copy-paste, you should ignore the last digit.

Re: Git email flow vs. GitHub flow

#80

Post by leephillips »

maeln wrote: post #55

> If your main complaint is that email is horrible to work with, the issue is most likely not email, it's probably your mail client. This is definitely talking from someone who never had to write software that deal with emails. The reality with emails ? They are an horrible format. There is several RFC describing the "email" format, the usual reference is rfc2822, but technically, you can find other rfc that relate t…

Email sucks less than any other communications protocol. The quote from the author is exactly correct. Users hate email because they use broken clients, like Gmail. Using a real client like mutt (https://lwn.net/Articles/837960/) is a pleasure; for one thing, it threads conversations correctly, unlike Gmail and almost everything else.
Post reply on HN