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

131–140 of 177 posts

Re: Git email flow vs. GitHub flow

#131

Post by rakoo »

WorldMaker wrote: post #117
u801e wrote: post #97

Earlier quoted context omitted.

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 g…

Given gmane's funding crises over the years, it feels hard to recommend relying on such a service long term. (Though I've certainly relied on it over the years for a number of different reasons.) What we almost need is an NNTP 2.0 that makes it easier for smaller federated groups. (Maybe this is a good use for ActivityPub and/or Matrix?) (Public-Inbox is new to me and at first skim seems to cover some interesting bas…

> What we almost need is an NNTP 2.0 that makes it easier for smaller federated groups.

We've had that with XMPP and Publish-Subscribe for years: if the project has a server with this XEP enabled, any authorized user (registered anywhere) can post any type of content.

Re: Git email flow vs. GitHub flow

#132

Post by yakubin »

ClumsyPilot wrote: post #129
yakubin wrote: post #112

Earlier quoted context omitted.

I have bothered to read the link. The point of those questions wasn't to see if there are answers to them. The point of those questions was to show that all answers to them are flawed. Yes, the link provides one set of answers. (Except for the backwards-compatibility and changing language question.) But it doesn't solve the problem. When you want case-insensitive search, it's the search tool's job to provide it. E.g.…

"The point of those questions was to show that all answers to them are flawed." Whats flawed? Where is it flawed? You provide no arguments at all! "When you want case-insensitive search, it's the search tool's job to provide it." I dont know if you didnt read it, or missed it, but the article clearlerly explains that the tool above the FS cannot do such a search performantly, it has to happen at the FS layer "You don…

Ok, maybe this you will judge as something constructive: when the underlying medium is case-insensitive, your application cannot behave in a case-sensitive way. But frequently I care about case-sensitivity in my searches. I gave an example in my top-most comment: "us" vs "US". On the other hand, when the underlying medium is case-sensitive, the application can implement case-insensitivity on its own. I do it all the time. Sometimes I want to run "find . -name", sometimes "find . -iname", and the first one not because I forgot about the second.

> Reading replies here convinces me even more that you just picked 'something something windows' and react like a bull does to a red rag.

Completely missed. I appreciate a lot of design choices behind Windows and use it with pleasure. However, I judge this one aspect of it negatively. It's also a source of recurring problems with Git on Windows.

Windows itself has case-insensitivity largely for backwards-compatibility reasons (from the times of MS-DOS). The underlying filesystem (NTFS) itself is case-sensitive, it is the OS API that normalizes filenames, and is itself case-preserving, rather than case-insensitive, when it comes to writing files.

UPDATE: another point: I may want to have a directory with an image for every character of my alphabet with files named accordingly. With a case-insensitive filesystem I can't have an "a.svg" and an "A.svg" in the same directory.

Re: Git email flow vs. GitHub flow

#133

Post by WorldMaker »

rakoo wrote: post #131
WorldMaker wrote: post #117

Earlier quoted context omitted.

Given gmane's funding crises over the years, it feels hard to recommend relying on such a service long term. (Though I've certainly relied on it over the years for a number of different reasons.) What we almost need is an NNTP 2.0 that makes it easier for smaller federated groups. (Maybe this is a good use for ActivityPub and/or Matrix?) (Public-Inbox is new to me and at first skim seems to cover some interesting bas…

> What we almost need is an NNTP 2.0 that makes it easier for smaller federated groups. We've had that with XMPP and Publish-Subscribe for years: if the project has a server with this XEP enabled, any authorized user (registered anywhere) can post any type of content.

PubSub alone isn't a great replacement for NNTP. (It's maybe a replacement for SMTP.) The reasons for an NNTP 2.0 (as mentioned above) are more about storage/forwarding, if you want access to the back history as opposed to just live updates. You can build such things on top of a PubSub protocol, as ActivityPub is at heart still a PubSub protocol, but has a lot more storage/forwarding concerns added on top, as an example.

Re: Git email flow vs. GitHub flow

#134

Post by Shared404 »

vxNsr wrote: post #106
Shared404 wrote: post #91

Earlier quoted context omitted.

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.

Can I ask what’s intuitive about a UX that hides all functionality behind cryptic commands that require reading the mind of the person who made them to know which three letters correspond to the acronym of the command you’re trying to run?

Perhaps intuitive is the wrong word.

Once you are familiar with it, it is easy to continue using, and much faster than fumbling around in a GUI trying to find the magic button.

For most commands it's also easy to find the necessary subcommand via man or -h or whatever. The other big thing is scriptability, there's a number of things I find myself doing a few times a day, I can throw that in a script (about a minute to do for most of them) and now they take .5 seconds to do, versus waiting for a GUI to load/run -- Plus, now it's my stupid 3 letter acronym I need to remember :P .

Re: Git email flow vs. GitHub flow

#135

Post by rakoo »

WorldMaker wrote: post #133
rakoo wrote: post #131

Earlier quoted context omitted.

> What we almost need is an NNTP 2.0 that makes it easier for smaller federated groups. We've had that with XMPP and Publish-Subscribe for years: if the project has a server with this XEP enabled, any authorized user (registered anywhere) can post any type of content.

PubSub alone isn't a great replacement for NNTP. (It's maybe a replacement for SMTP.) The reasons for an NNTP 2.0 (as mentioned above) are more about storage/forwarding, if you want access to the back history as opposed to just live updates. You can build such things on top of a PubSub protocol, as ActivityPub is at heart still a PubSub protocol, but has a lot more storage/forwarding concerns added on top, as an exam…

XMPP Core is a replacement for SMTP. XMPP pubsub is much more than just pubsub, take a look at https://xmpp.org/extensions/xep-0060.html. There is everything about querying and forwarding, in this XEP and in https://xmpp.org/extensions/xep-0313.html. There is precedent for posting content and replying inside XMPP's pubsub as documented in https://xmpp.org/extensions/xep-0277.html; the same can be used for general discussions

Re: Git email flow vs. GitHub flow

#136

Post by gkya »

u801e wrote: post #95
gkya wrote: post #65

Earlier quoted context omitted.

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

Didn't know Thunderbird did NNTP, thanks!

Can you get your own mailing lists on public-inbox, or would you have to self host? I'd love to self host git and a mailing list but setting up mailman/sympa/etc. seems to be too big a task. I was thinking setting up a wiki as a replacement for my small personal projects...

Re: Git email flow vs. GitHub flow

#137

Post by rectang »

masklinn wrote: post #127
rectang wrote: post #113

Earlier quoted context omitted.

A pull is just a fetch followed by a merge. So to solve this problem, just fetch instead of pull! Then do `git merge --ff-only` and if it doesn't work, do the rebase or whatever else to resolve the conflict. I did this long before I set `merge.ff=no`. I hate it when pull creates crappy graphs — it's something I try to help all my colleagues to avoid. I often wish that `git pull` didn't exist.

> A pull is just a fetch followed by a merge. So to solve this problem, just fetch instead of pull! Of course, that’s what I do. But “git pull” is still a danger, and configuring merge.ff=only protects against that danger.

Why is `git pull` a "danger" if you always use `git fetch`? The configuration setting for merge.ff only affects the local machine. It doesn't generally impact other developers.

(Unless you're doing something like setting the system gitconfig on a shared dev box, and setting merge.ff to anything other than the default would be really heavy handed in such an envronment.)

Re: Git email flow vs. GitHub flow

#138

Post by mixedCase »

ClumsyPilot wrote: post #130
mixedCase wrote: post #122

Earlier quoted context omitted.

I read it, even though you could be succintly making your points here instead of linking generic articles, and that's why I surfaced the only thing I considered valid. The usecase you bring up, including the multiple scripts issue, is search. And it's not and should not be a filesystem concern which optimizes for a different kind of access from which you can build search on top of.

The article is not generic, it is spesific to the issue being discussed, and it explains the issue better than I can. "And it's not and should not be a filesystem concern which optimizes for a different kind of access" Why not? Is that by Pope's decree, or is there an actual reason for that? The filesystem already has like 3 different APIs, with and without caches, sync and async, so clearly they do optimise for diff…

> Why not? Is that by Pope's decree, or is there an actual reason for that?

By the decree of it vastly increasing complexity and drastically changing the very generic problem a filesystem tries to tackle, instead of just isolating it to its own solution for when it's actually needed and the trade-offs make sense.

> with and without caches, sync and async, so clearly they do optimise for different kinds of access.

That are compatible with the previously existing patterns. Case-insensitive/mapped codepoint full-text search is a very, very different problem and for which you should reach out to the right solution.

And if you want it in your file browser, well nobody's forcing your operating system's human-facing file browser to base its UX entirely on file system primitives.

As for existing tools, I don't know, I don't care for them since I can just organize my files and find them with fd or use a mapping tag-based file-system like tmsu. But I would assume this is the kind of usecase KDE's Baloo or GNOME Tracker intend to solve.

Re: Git email flow vs. GitHub flow

#139

Post by WorldMaker »

rakoo wrote: post #135
WorldMaker wrote: post #133

Earlier quoted context omitted.

PubSub alone isn't a great replacement for NNTP. (It's maybe a replacement for SMTP.) The reasons for an NNTP 2.0 (as mentioned above) are more about storage/forwarding, if you want access to the back history as opposed to just live updates. You can build such things on top of a PubSub protocol, as ActivityPub is at heart still a PubSub protocol, but has a lot more storage/forwarding concerns added on top, as an exam…

XMPP Core is a replacement for SMTP. XMPP pubsub is much more than just pubsub, take a look at https://xmpp.org/extensions/xep-0060.html . There is everything about querying and forwarding, in this XEP and in https://xmpp.org/extensions/xep-0313.html . There is precedent for posting content and replying inside XMPP's pubsub as documented in https://xmpp.org/extensions/xep-0277.html ; the same can be used for general…

Fair points. I wasn't aware of any of these tools, but then like the majority of the world I haven't actively used XMPP in years (which is obviously among its largest cons today).

Re: Git email flow vs. GitHub flow

#140

Post by u801e »

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…

> Yes, some make use of Thread-id a bit better than other

Traditional email threading was based on the contents of the In-Reply-To and References headers. The algorithm is described in RFC 5256 for the IMAP SORT and THREAD extensions[1] and used in several mail user agents[2].

[1] https://tools.ietf.org/html/rfc5256#ref-THREADING

[2] https://www.jwz.org/doc/threading.html

Post reply on HN