81–90 of 177 posts
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...
Why would you ever want a case insensitive file system?
Earlier quoted context omitted.
Well, there are different views of "appropriate". When you do team development and everything is done via feature branches, it's nice to have merge commits so that the integrity of the each feature development effort is preserved via a merged branch in the history. If everything is flattened, it's harder to see where the branches (standing in for development initiatives) begin and end. You can't always get fast-forwa…
Do you at least agree that merge commits for single-commit PRs aren't "appropriate"?
A good clean fast-forward merge of a single-commit PR is fine. But I've also worked at multiple jobs where every merge to the production branch created a merge commit and that's also fine. It adds a bit of complexity to the history graph, but it's not meaningless complexity.
If your commit history is majority single-commit PRs then having additional merge-commits everywhere would be noisy, so in that case it would be too much. I don't tend to work on actively developed projects that match that pattern, though. Most feature development involves multiple-commit branches.
> 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
The format / protocol do impact and limit what the client can do. In a funny way, thanks to MIME, you can technically do whatever you want with emails, but that will be a poorly organized and structured whatever. In many way, emails are like HTML : A way to present information, not to structure and/or organize it. And therefore, there is only so much the client can figure out about the email. Thanks to Thread-id and the recipient list, you can group emails more easily and more relevantly, but that is about it.
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/
> 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.
> 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…
Otherwise, yes, email message format is a mess. I also had a pleasure of writing a MIME mail message parser in C. But it was quite fun to try to do it in streaming fashion with no dynamic memory allocation allowed.
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…
So if someone wanted a review of some changes all that was necessary was to push their current status to a tag, which is a single command in git. No git-send-mail setup needed.
It was quite nice middle ground, and didn't require me to use github/gitlab GUI. Being able to stay in neomutt for most communications was nice.
Platforms like GitHub and GitLab should support a workflow consisting of series of patches instead of a specific commit on a particular branch. They could probably even show pull requests from email in their interface.
Something like:
git push master:email/v1
You can easily make a git hook script to do it with regular ssh/http based git hosting.
> 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…
Once, many years ago, I started writing a library for dealing with IMAP mailboxes. My take way is I have no idea how on earth people have actual working IMAP implementations.