Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Code Annotations for SourceHut

drewdevault.com

Post reply on HN
Print view View original

31–35 of 35 posts

Re: Code Annotations for SourceHut

#31

Post by PyroLagus »

Sir_Cmpwn wrote: post #13
asdkhadsj wrote: post #10

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.

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

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

Re: Code Annotations for SourceHut

#32

Post by rjeli »

asdkhadsj wrote: post #10

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.

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.

Re: Code Annotations for SourceHut

#34

Post by asdkhadsj »

panopticon wrote: post #30
Sir_Cmpwn wrote: post #29

Earlier quoted context omitted.

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.

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.

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.

Re: Code Annotations for SourceHut

#35

Post by asdkhadsj »

rjeli wrote: post #32
asdkhadsj wrote: post #10

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.

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.

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.
Post reply on HN