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

61–70 of 177 posts

Re: Git email flow vs. GitHub flow

#61

Post by progval »

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…

Not disagreeing with your overall point, but:

> - mailing lists software exist but they are another hack. There is no standard for subscribing or unsubscribing

There is a standard for unsubscribing: https://tools.ietf.org/html/rfc8058

And for subscribing, you can often open a mailto: link.

Re: Git email flow vs. GitHub flow

#62

Post by progval »

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?

https://useplaintext.email/ has some recommendations, and is written by the sourcehut devs

Re: Git email flow vs. GitHub flow

#63

Post by gocartStatue »

chii wrote: post #60
gocartStatue wrote: post #38

Earlier quoted context omitted.

For small, integrated teams, github flow may be suboptimal. Frequent merging to master, aka trunk-based development, aka Continuous Integration is the way to go for me.

> trunk-based development, aka Continuous Integration continuous integration isn't trunk-based development (where everyone merges into the same master branch)!

I love pasting that quote :)

"The idea that developers should work in small batches off master or trunk rather than on long-lived feature branches *is still one of the most controversial ideas in the Agile canon*, despite the fact *it is the norm in high-performing organizations such as Google.* Indeed, many practitioners express surprise that this practice is in fact implied by continuous integration, but it is: The clue is in the word “integration.”

[State of DevOps report 2016]

Re: Git email flow vs. GitHub flow

#64

Post by ClumsyPilot »

rectang wrote: post #18
ryukafalz wrote: post #15

I like the decentralization aspect, but every time I've had to send patches by email... it definitely has not been as straightforward as the pull-request workflow. I suppose part of that has to do with the project I have experience with using Debbugs (which requires that subsequent patches in a patchset be sent to a newly created address rather than all of them being sent to the same email address). I might like it b…

Yeah, I've got strong git skillz and could handle the email workflow, but I prefer to work with branches rather than a bunch of loose patch files. There are a couple things I strongly dislike about Github though. Number one: the default commit history display with commits force-linearized by date, which is just messed up and wrong when actual Git history can only be properly modeled with a topological view revealing…

This, a thousand times this. I fail to understand how such an established and well funded project can lack somethong so basic, so core to the entire system.

Every time I see people doing a dance and paising billion dollar companies like netflix, uber or deliveroo, I check them out, realise that they lack most essential functionality:

Deliveroo didn't have Search(!) For restaraunts for like a year

Netflix will sell you a 4K plan, but if your system has 4K screen but does not satisfy their '4K requirements' it won't tell you that you aren't gonna get 4K or what you are missing.

Uber outright used to lie about time to arrive, in London all taxis were always 4 minutes away.

So I I often wonder, we pulled resources and finance in billions across the world, and this is the best we can do?

Re: Git email flow vs. GitHub flow

#65

Post by gkya »

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/

Re: Git email flow vs. GitHub flow

#66

Post by yunohn »

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?

+1 to this. I’ve been searching high and low for a good email client that supports Gmail and Outlook (via OAuth for security). Ideally, it should also work across MacOS and iOS too.

Re: Git email flow vs. GitHub flow

#67

Post by ryukafalz »

arghwhat wrote: post #49
ryukafalz wrote: post #15

I like the decentralization aspect, but every time I've had to send patches by email... it definitely has not been as straightforward as the pull-request workflow. I suppose part of that has to do with the project I have experience with using Debbugs (which requires that subsequent patches in a patchset be sent to a newly created address rather than all of them being sent to the same email address). I might like it b…

> it definitely has not been as straightforward as the pull-request workflow. I agree - there's a bit of a setup phase, stemming a from email having degraded into "that thing you see on gmail.com". https://git-send-email.io/ is nice for validating the setup when in doubt. However, once the flow runs, I think it's more straight forward than a pull-request workflow. > I do also like being able to update an existing PR…

> Rapid changes to a PR is bad etiquette. Submit a PR for review, await comments, when received, prepare fixes and submit a new iteration.

I think this depends a lot on context. GitHub now lets you open "draft" PRs, which are explicitly unmergeable until you mark them as ready. If I'm unsure of the approach I'm taking, it's helpful to be able to show my team what I have and ask for feedback before I've done the work to polish it to a mergeable state.

Surely I'm not the only one who finds this useful, or the feature wouldn't exist.

Furthermore, it's also helpful when collaborating on something that's not code via a PR. For example, I've used git to collaborate on documents; as far as I'm concerned it's much better to have a tight feedback loop between the comments I receive and the edits I make to the document. There's not one "right" way to word things, and I'm not necessarily the only one working on that document, I just happened to be the one to start it; allowing other people to suggest small edits to the document piecemeal more closely matches the kind of collaboration I'm actually looking for.

Re: Git email flow vs. GitHub flow

#68

Post by ClumsyPilot »

IgorPartola wrote: post #9
javitury wrote: post #6

Reading this article has changed the impression I had about git-mail-flow. Naturally, more questions came to my mind. Is a git-mail-flow compatible with continuous integration? Yes, it seems to be https://sourcehut.org/blog/2020-07-14-setting-up-ci-for-mail... Is it possible to construct ergonomic workflows around a git-mail-flow? I suspect you could do it with notmuch and alot, although I wonder which tools do sourc…

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

Re: Git email flow vs. GitHub flow

#69

Post by MartijnBraam »

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…

I actually have written email software before (and dealt with the horrors of IMAP and MIME), but that's no tthe point of that sentence, it's about email management and not having your email client do stupid things. not about using the protocols

Re: Git email flow vs. GitHub flow

#70

Post by andrius4669 »

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

Post reply on HN