[asdkhadsj]

So excited to use this once my requirements are implemented (mostly just LFS, and to a lesser extent Merge(|Pull) Requests). Admittedly I don't need it, I just really appreciate the simplistic UI and straight forward pricing model.

[Sir_Cmpwn]

LFS support is something I'd like to do, but It's Complicated(TM). Main challenges include finding a good place with ample bandwidth and storage, figuring out where/how to take backups of it, and measuring bandwidth and storage usage to integrate with billing. Not a priority right now, but may land between the beta and stable periods.

As for merge requests, don't hold your breath. SourceHut embraces the email-based model. A tutorial is available here to give you an idea of how it works: https://git-send-email.io and check out this video for the maintainer's side: https://aerc-mail.org/

The advantages of email include:

- It's based on a venerable and well-understood standards, with ample open-source tooling available

- It's decentralized, federated, and highly fault tolerant

- It doesn't lock you into my platform, you have ownership over your content and can freely interact with projects anywhere

It's also easy and natural to review code by writing emails, and by far the most efficient workflow for git collaboration I've used (having extensively worked in email, GitHub, GitLab, and Gerrit). I think you should give it a chance!

[PyroLagus]

Well, technically (and as I'm sure you already know) pull requests are email-based[1] (they are used for Linux kernel development after all), so SourceHut already "supports" it. It could make sense to leverage that in the web UI. User A, who prefers email, emails the output of git request-pull to the mailing list, while user B, who prefers web, presses some button that does that for them. Doing the actual pull would work similarly. It also shares the advantages you listed, although an emailed patch stays in your mailbox backups forever, whereas a pull request URL could become invalid. That said, I'm sure it's easy to underestimate the effort it takes to build a nice pull request UI.

It definitely would make SourceHut more attractive for many people, but so would a nice Git plugin for VS Code that provides a nice UI for automating the git send-email process.

[1] https://git-scm.com/docs/git-request-pull

[Nextgrid]

My issue with emails is that the user experience isn't as good and while it can be a worthwhile tradeoff for the points you mention, most of them are irrelevant in an enterprise setting (think using an internal SourceHut server instead of self-hosted GitLab or Bitbucket Server) so the UX benefit would be very much welcome.

[Sir_Cmpwn]

I honestly disagree that the user experience isn't as good, and I don't think people have enough faith to try it out for a while. I've spent thousands of hours in many workflows and I still find email to be the easiest and most efficient way of doing it.

However, I don't focus on the enterprise crowd, you're right about that.

[panopticon]

While that's probably true for seasoned OSS contributors, I think the email model is a tad abrasive for new/casual contributors.

I'm not necessarily saying it's the right choice for Source Hut, but I think it's part of the reason why Github is quite successful in the open source community.

[asdkhadsj]

I also think we're conflating use cases. Email is likely more efficient, I don't debate that. Yet I don't want it because of the time I do spend in a PR/MR UI (be it email or web ui) is so minimal that I want the process to be nearly fire and forget. The thought of learning some CLI based email client just so that I can merge a branch from someone else once a month feels.. well, it screams that it'll become like a Unix tool I rarely use.

I feel like he's asking me to open up Emacs every time I want to PR/MR, but I'm a Vim user. I don't have any email workflow currently, and I don't want to have to figure it out for a problem I don't have. He's telling me it's more efficient, but most cost vs savings ratio seems very off compared to what I imagine his is.

I don't disagree with anything he says about email, yet I have zero desire to try it out. If I was getting multiple MRs a day, or god forbid dozens a day, yea I'd be dying for something more efficient. But in the Emacs example, I wouldn't mind opening it if I was going to be doing it regularly.

Being required to use a workflow that you rarely use and is always in the "how did I do x?" part of your brain is a hard selling point for me. Even if that workflow is better, if I never remember how to use it what does it matter? It's still worse for me.

[rjeli]

Why not run your own LFS server? We use https://github.com/artemkin/git-lfs-server with GitHub and it works fine, big ML models are pulled from a local server.

[asdkhadsj]

That's interesting - though part of why I like them to host the LFS is because I want the additional backups. It's definitely food for thought - the only LFS servers I've seen have been WIP / not-production-ready sort of things.