Hacker News Reader

Comment by belltaco | Hacker News Reader

>They embraced git, and then rather than building an interface on top of email — the collaboration mechanism that git was designed to use, and which is still used for Linux kernel development — they built their “pull requests” mechanism.

How is git designed to use email?

>Sarah Novotny, Microsoft employee, transitive owner of GitHub, and patroness saint of conflicts of interests

Followed by:

>I represent sourcehut, a GitHub competitor which does what GitHub wouldn’t — interoperate with open, distributed protocols, and in the form of 100% free and open-source software

Yeah no conflict of interest there /s

View on HN

> How is git designed to use email?

https://git-scm.com/docs/git-send-email

https://git-scm.com/docs/git-format-patch

Still for those unfamiliar -- these are standard utilities that are part of every git installation.

There's also `git am` (as in "apply mail"), also standard part of git.

https://git-scm.com/docs/git-am

The whole workflow of git is based around email: the commit message requires a Subject line, then a blank line, followed by the description of what the patch attempts to solve.

The reason patches are required to be sent as plain-text for Linux and OpenBSD is that you can save the whole email, and pass the contents of the whole email to git (in case of Linux) or the patch(1) command (in case of OpenBSD -- the patch command will automatically ignores all the headers and non-patch part of the body of the email). This guarantees you won't end up with undocumented random patches on your filesystem -- each patch has the accompanying documentation as part of the same file, metadata on authorship etc. But if you use weird encodings, then the workflow breaks down.

>How is git designed to use email?

git was designed for use with the Linux kernel, which has collaborated over email since its inception. It includes many features for email-based collaboration out-of-the-box with no need for a centralized hosting service of any kind.

https://www.git-scm.com/docs/git-send-email

https://www.git-scm.com/docs/git-request-pull

https://git-scm.com/docs/git-am

https://git-scm.com/docs/git-imap-send

Both Linux and git itself are developed via email, along with dozens of other projects, *BSD, gcc & clang, coreutils, busybox, ffmpeg, qemu, PostgreSQL, vim, emacs, most Linux distros...

Those projects have found git's email collaboration model to be a great bozo filter.

All those don't sound like git was designed to be used with email.

>It includes many features for email-based collaboration out-of-the-box with no need for a centralized hosting service of any kind.

What many features?

I listed these features. Email is in the name of one of them, IMAP (an email protocol) is in the name of another, one is short for "apply (e)mailbox", and the fourth one generates an email.

If you're not going to argue in good faith then don't leave a comment in the first place.

All those don't sound like git was designed to be used with email, those projects using email to collaborate sounds like a coincidence and orthogonal to me.

>It includes many features for email-based collaboration out-of-the-box with no need for a centralized hosting service of any kind.

What many features?

The fact that you refer to those internal commands that are part of every Git installation as "projects" shows that you're likely unfamiliar with Git CLI.

Because git is so large, every individual command is documented in a separate manual page, with `git diff` being documented in the `git-diff` manual page, and so forth.

All the mentioned commands are probably present on your Mac in Apple's distribution of Git, for example. Even though Apple probably doesn't use any of those commands for internal development (because big corp, and not invented here).

That's a weird argument. Linus wrote git to be his tool for developing the Linux kernel. Every single thing about the Linux kernel workflow is what git was designed to be used with.

(you replied twice)

I listed these features. Email is in the name of one of them, IMAP (an email protocol) is in the name of another, one is short for "apply (e)mailbox", and the fourth one generates an email.

If you're not going to argue in good faith then don't leave a comment in the first place.

> How is git designed to use email?

https://www.git-scm.com/book/en/v2/Appendix-C%3A-Git-Command...

>Yeah no conflict of interest there /s

It is amazing to me that anyone could seriously look at (1) a virtually unknown company celebrating FOSS principles and (2) a trillion dollar company working to undermine those same principles and be so foolish as to conclude that those are comparable examples of conflict of interest.

Love the pricing page. It literally doesn’t list features to distinguish the variations by...

If you read the big, ~read~ red and nearly glowing banner above it you'd see that:

> Notice: sr.ht is currently in alpha, and the quality of the service may reflect that. As such, payment is currently optional, and only encouraged for users who want to support the ongoing development of the site.

There are no features to distinguish the variations by - they're all donations, effectively.

Though i admit they could improve that UX further still. But, imo - the entire product is not super polished for "mainstream users" (of which i mean nothing against), so polish in this specific area might be cart-before-horse.

Isn't the whole point that there aren't any differences? All users get the same features. You choose how much you pay.

Literally the first lines of text on the page:

> sr.ht is the hosted instance of sourcehut and provides paid services to its users. On sr.ht, all plans have access to the same features, at the same level. You should pick the plan which best matches your financial needs and best represents the level of investment you have in sourcehut.

From: https://sourcehut.org/pricing/

Reply on news.ycombinator.com