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

91–100 of 177 posts

Re: Git email flow vs. GitHub flow

#91

Post by Shared404 »

vxNsr wrote: post #23
IgorPartola wrote: post #9

Earlier quoted context omitted.

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

Inconvenient to who? There a many things in Linux that anyone who doesn’t use Linux full time finds majorly inconvenient, a lot of the UX around Linux is only intuitive to the 45 year old graybeard. To us 30 year old win DevOps guys Linux isn’t actually that “convenient” out of the box.

19 year old DevOps/Sysadmin here, gonna have to disagree.

I can work with Windows, but I hate every second of it. Meanwhile, Linux/BSD is intuitive and easy to get going.

Almost like what tools you know impact what you find easy.

Re: Git email flow vs. GitHub flow

#92

Post by Shared404 »

tasogare wrote: post #36
edgyquant wrote: post #26

Earlier quoted context omitted.

They were talking about development of the Linux kernel, not using the OS. But I also take issue with your “graybeard” comment. Unix has won out for a reason, I and many other who aren’t old hats prefer the flow of development and deployment on Linux/Unix to that of Windows.

> Unix has won out Nop, it doesn’t. Linux, which is a Unix clone , has won on some category of computers (notably servers) but most unices derivativing from the original one have a marginal market share. > for a reason Price mostly, and access to sources.

Mac is still certified Unix iirc, and FreeBSD powers at least Netflix, so it seems Unix proper is still sticking around.

Re: Git email flow vs. GitHub flow

#93

Post by colejohnson66 »

maeln wrote: post #79
andrius4669 wrote: post #70

Earlier quoted context omitted.

>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.

How do you copy paste something so wrong that it adds a random digit to each number?

Re: Git email flow vs. GitHub flow

#94

Post by [deleted] »

swiley wrote: post #74
ClumsyPilot wrote: post #68

Earlier quoted context omitted.

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.

[deleted]

Re: Git email flow vs. GitHub flow

#95

Post by u801e »

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/

> No "good" NNTP clients

Thunderbird works on most platforms.

> Gmane was relatively popular, and it was great but went down for a long time

Some mailing lists are now archived using public inbox[1]. There are several ways to access it including via NNTP.

[1] https://public-inbox.org/README.html

Re: Git email flow vs. GitHub flow

#96

Post by colejohnson66 »

swiley wrote: post #74
ClumsyPilot wrote: post #68

Earlier quoted context omitted.

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.

But why? Why are they a bad idea besides “Windows does it and ‘Windows bad’”? Why is DNS case insensitive (example.com and EXAMPLE.com are the same), but not files (.Xauthority and .xauthority are different)?

Case insensitivity lines up with the average user’s expectations. For example, if I’m searching for a file, I want a case insensitive match. Because if I named a file “Resume.txt” and searching “resume” didn’t bring it up, I’d be pretty confused. Now imagine the average Joe trying it. Explaining to them case sensitivity won’t convince them it’s a good idea because “Resume” and “resume” are the same thing.

Re: Git email flow vs. GitHub flow

#97

Post by u801e »

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…

I've brought up the same point in a number of threads that have brought up mailing lists over the years. In the specific case of mailing lists like the ones used for Linux kernel and git development, I believe many participants host their own SMTP instances and use them to send and receive messages and have had those set ups for a long time.

If they were to switch to NNTP, they would either have to:

1. Create a new group on usenet (and have to somehow filter out all the spam posted to it or everyone will have to keep their NNTP client kill file up to date)

or

2. They each would have to host their own NNTP server and each one would have to add enough peering servers (incoming and outgoing) to ensure that articles are propogated to them and articles they post are propagated to others

or

3. The maintainer would have to set up a authoritative NNTP server and allow read access, but then have to add accounts for those who need write access (in order to allow them to submit patches).

Continuing to use SMTP allows them to essentially choose option 2, but not have to set up peering servers since DNS MX records handle propagating the emails they send.

That said, having a NNTP mirror of a mailing list like gmane[1] and public-inbox[2] provides the best of both worlds. You get the benefits of NNTP for reading the mailing list, but get the benefits of propagation via SMTP.

[1] https://gmane.io/

[2] https://public-inbox.org/README.html

Re: Git email flow vs. GitHub flow

#98

Post by ori_b »

maeln wrote: post #86
leephillips wrote: post #80

Earlier quoted context omitted.

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.

I used mutt, thunderbird, apple mail, outlook, gmail, sogo, roundcube and they pretty much all have the same issues. Yes, some make use of Thread-id a bit better than other (I like the way apple mail show thread and thunderbird is "okay", although sometimes it handle edge case in a weird way), but overall, they cannot fix fundamental flaws in the format in itself: Emails are hard to search, the threading model is sim…

I'm currently touching the plan 9 email tools a lot, and recently rewrote the acme mail client. There are warts, of course, but the ones you've discussing are either related to the underlying communication and not the format, or are easy to deal with.

I'm not sure why you say emails are hard to search. Extract the text and put it into an engine like lucene. There are the usual small corpus problems, but these aren't dependent on format.

As threads are fundamentally a graph, so complaining that the structure matches the structure of the data is... Odd.. to me.

Including the time zone in the date is a small wart. Add an extra specifier to the format string and move on. Base64 is similar: a bit annoying, but decode and move on. And use RFC1652.

Re: Git email flow vs. GitHub flow

#99

Post by thcipriani »

I believe what this post is describing is two different integration patterns and not two different workflows: continuous integration[0] vs long-lived branches.

Martin Fowler has a good post on the subject: https://martinfowler.com/articles/branching-patterns.html#Co...

tl;dr: if you make big feature branches and take a lot of time to integrate them it's a painful process.

[0]: https://www.thoughtworks.com/continuous-integration>

Re: Git email flow vs. GitHub flow

#100

Post by leephillips »

ori_b wrote: post #98
maeln wrote: post #86

Earlier quoted context omitted.

I used mutt, thunderbird, apple mail, outlook, gmail, sogo, roundcube and they pretty much all have the same issues. Yes, some make use of Thread-id a bit better than other (I like the way apple mail show thread and thunderbird is "okay", although sometimes it handle edge case in a weird way), but overall, they cannot fix fundamental flaws in the format in itself: Emails are hard to search, the threading model is sim…

I'm currently touching the plan 9 email tools a lot, and recently rewrote the acme mail client. There are warts, of course, but the ones you've discussing are either related to the underlying communication and not the format, or are easy to deal with. I'm not sure why you say emails are hard to search. Extract the text and put it into an engine like lucene. There are the usual small corpus problems, but these aren't…

Indeed. Also, tools like grepmail make big mailboxes easy and fast to search through.
Post reply on HN