Hacker News Reader

Comment by PaulDavisThe1st | Hacker News Reader

Within the first 5 minutes, the presentation claims that "the tools are unusable without a global central server".

I really don't know what that is supposed to mean. Plemty of people do in fact use github, but I don't know why anyone would say that git in particular is "unusable" without a global central server.

Github (etc.) are conveniences for people who don't want to self-host. They provide some additional tools that can be useful in some situations. But nothing more.

View on HN

There are vast swaths of devs who are not aware people still use mailing lists, nor that git has first class support for applying patches from emails.

And that this is not just a minor niche use case, "the largest and oldest Git project that is, Linux, uses a mailing list and patch files to develop."

it is definitely not the oldest

In the sense that it was the first project to use git (has been using git the longest), not in the sense that it's the oldest project that switched to git.

> it is definitely not the oldest

IIRC, the oldest was git itself (it self-hosted early on its development history); git, linux, and sparse are IIRC the three projects that have been using git the longest.

TBH I definitely consider Linux a niche use case. It’s an outlier relative to 99.99% of projects.

How can Linux be a niche use case for git if git was made as a version control system for Linux?

Niche use cases are a great reason to make a bespoke tool! But that doesn’t make it not a niche use case. And it doesn’t mean that tool is optimal for the common use case.

Note that Linux, today, is far from the largest Git project. Oldest, yes. Biggest, not even close. FAANG monorepos are vastly bigger with much higher commit rates. The Linux kernel is quaint, small, and moves glacially slow in comparison. Even if we consider only public open source codebases, Chromium's repo is bigger than Linux by any reasonable metric.

... apparently ... that's rather absurd ... perhaps I won't listen to this presentation when time might allow, for the moment.

https://youtu.be/1Npo0cmp-VY

On second thought, let's not go to Camelot, tis a silly place.

We don't even do that. ardour.org self-hosts gitea, and that allows for PRs etc. We don't expose that to "the public", for now, just because github is familiar to more people. But we could.

I self-host Gitlab, which is pretty familiar to people, but I still mirror repos for which I'm hoping to get contributions to GitHub for the same reason

> git has first class support for applying patches from emails.

You say that like it's a good thing.

No-one should be applying patches from emails. I know several people will react with certainty that I'm wrong, but email-patch-based flows are just used because the old-timers using them are very accustomed to it.

It makes vastly more sense to transmit a patch attached to the specific code base state that it is intended to modify: in other words a patch doesn't exist in isolation. Git is great; I'm not saying everyone should use any particular Git-hosting or code review framework. But the fact that the inventor of Git continues to use email in one particular project with many expert and experienced contributors has more to do with their expertise and experience (aka age) than with the benefits of email. I mean look at the reality of these people's workflows: they're using things like Mutt and Gnus to read email locally and apply patches from local email. I get it, I've done it, I've even run a local dovecot for the purpose. It had it's time in technological history. That time isn't now.

There are multiple open source projects that I would have contributed to were it not for the email-based flows (e.g. emacs).

I strongly disagree. I've recently contributed to a project that uses an email-based workflow, and find it considerably easier to use: after a surprisingly brief one-time setup, I can contribute patches using a single `git send-email` command from the same terminal that I make my commits, and can review and comment on patches from my email client of choice (thunderbird) – all without needing to create a new account.

Applying patches is, admittedly, a little more awkward, but it can still be done in two or three steps from thunderbird (including invoking `git am`) and, I understand, some newer email clients can handle this much much better.

> It makes vastly more sense to transmit a patch attached to the specific code base state that it is intended to modify:

This is no longer a problem. `git send-email` (and `git format-patch`, if you prefer to call it directly) has for a while supported a `--base=auto` or the `format.useAutoBase` configuration option to attach the upstream commit ID to the patch. To my knowledge this is currently only to help the maintainer understand its context but there is ongoing discussion of ways to automatically use this information.

How is that better than having shared access to a remote git repo and your collaborator sending you a commit sha and branch name?

Note that I'm not suggesting you use any for-profit company's hosted git product.

The biggest difference is the need to have shared access and it therefore does not easily allow for contributions from people without write access to the repo, although a similar workflow is possible with multiple publicly-readable repos (esp. with the help of `git request-pull`). Another advantage a send-email–based workflow has (compared to the workflow you describe, at least) is that the presence of the patch in the email makes it trivial to respond to specific code changes inline, using standard email quoting.

ETA: Many forges reintroduce the latter (commenting directly on lines of code), in which case this may not be an advantage depending on if such a forge is used. (But then you're back to using a forge, and needing to open the website to review changes in addition to using git and email.)

> But then you're back to using a forge, and needing to open the website to review changes in addition to using git and email.

It sounds to me, and I mean this quite objectively, not as a personal insult, that you're attracted to the email-based flow not because it is better, but because you just don't want to use a web UI. So since you define web UI as bad, you of course reach the conclusion that the email-based flow is better.

I'm not sure I phrased that correctly. The point I was trying to get across with that sentence was not so much that web UIs are bad, but that if you are using a forge with in-browser support for reviewing changes (generally in the context of pull requests), then there is little benefit to sending "a commit sha and branch name" separately. Similarly, send-email–based workflows have little need to manage the repository in the browser. Email-based workflows and pull-request-based workflows are parallel in that they provide the same features in different ways.

We can quibble about which is more convenient (admittedly I find the former better in this regard, although I recognize that this is a minority opinion), but they are IMO both more-or-less equally viable choices.

Perhaps I should have been more explicit: sending "a commit sha and branch name" is functionally equivalent in that it contains both the information necessary to retrieve the commits and a method of responding to the new commits, but is considerably less convenient. There is an extra step in sending the commit (you must push the commit then send the relevant data using a separate email client), and the resulting email lacks both the commit message explaining what was changed and why, and the changes in question, requiring one to manually examine the commits out-of-band. This is in addition to the need for all contributors to have write-access to the repository, mentioned above.

It is, however, also functionally equivalent to a pull request, excepting again the need for write-access.

I have used git without a central server many, many times. Passing bundles by email or USB sticks, and pushing and pulling between workspaces. At work, it is because we have often have different networks, isolated for security reasons. For personal use, I don't really have a central server. I may use GitHub, because it offers free hosting and serves as a backup, but it isn't central in the sense that it is not always the git-remote "origin".

It may not be the most typical workflow, and it requires some getting used to but it is 100% usable. In fact, I am not aware of a "central server" for the Linux kernel. For all I know, the closest thing to it could be Linus Torvalds's PC.

Reply on news.ycombinator.com