Git without a forge • Hacker News Board

Re: Git without a forge

#161

Post by Ferret7446 » Sat, Mar 08, 2025, 11:23 AM UTC

bjackman wrote: post #9

MaxBarraclough wrote: post #4

This reminds me of Drew DeVault's advocacy for the traditional email-driven git workflow. [0][1] (Drew is the creator of SourceHut, an email-oriented git forge.) I think his (Simon's) objection to git send-email emails could be addressed with better tooling, or better use of them. It's 'just' a matter of exporting the emails into a single mailbox file, right? (I'm not experienced with git's email-driven features.) It…

It doesn't work smoothly for Linux kernel folks. It's a huge pain in the arse to review code. Some subprojects have CI but mostly it's too much work to set it up. You never know if the code that gets merged is truly what got reviewed. Half the time if you wanna test out someone's patches you have to spend 20 minutes trying to figure out what base commit they even apply to. Old fashioned mail clients are huge pain to…

How do you know it's not a personal tooling issue? I have had very smooth email workflows using GNUS, and I imagine many Linux devs have their own scripts and/or customized clients to handle the email flow.

An argument could be made that developers shouldn't have to build their own workflow to do basic development tasks, but given Linus's past statements on C++ developers, I would assume that he would rather not have developers that cannot handle an email workflow working on Linux (that is, this is WAI).

Re: Git without a forge

#162

Post by Ferret7446 » Sat, Mar 08, 2025, 11:32 AM UTC

satvikpendem wrote: post #149

KomoD wrote: post #145

Earlier quoted context omitted.

> What does "2FA" stand for? Two factor authentication, I'm sure you can google it. > The passkeys that you (and GitHub) are talking about require a separate authenticator to use. I'm not using anything other than my browser. > You have already indicated a willingness and desire to use an authenticator I'm only using my browser, it was 1 click. > This is all before we even mention that you have to set all this up. Ye…

> Two factor authentication, I'm sure you can google it. The question was rhetorical, they are showing how a passkey is also a form of 2FA.

It's not, though. The passkey itself is strictly a single factor. That's kinda the point, to reduce user toil.

Your passkey could have 2FA locally (e.g., a Yubikey with a PIN), but that is up to your discretion. It may be single factor.

Re: Git without a forge

#163

Post by notpushkin » Sat, Mar 08, 2025, 12:57 PM UTC

mikepurvis wrote: post #160

notpushkin wrote: post #93

Earlier quoted context omitted.

Probably. We’re looking at three roundtrips here: one to fetch the HTML, one for the JS, and at least one for the packfiles (and that’s if you can do that in parallel). If the latency is high, the result can be... not great. HTTP/2 should help with this a bit, but it’s better to not have this problem at all IMO. Of course, there’s also the argument that if you’re self-hosting a repo, you’re more likely to care about…

If you render the repo home/tree/readme statically but serve the JS application upfront with that, then successive clicks into files/commits/diffs will only have to pull packfiles, and then only if the content isn't already present locally. Packfiles are obviously immutable so they can be set for infinite caching, which should mean that even successive visits could be pretty speedy.

Yeah, the question is basically which entry pages you want to support. I think it’s nice to be able to link to a particular file on the master branch and have it load instantly, too. Loading older verisions, on the other hand, has its uses but is less important.

For a repo with thousands of files, it might make sense to limit entry pages to only directories and .md files (and other prose files), which are more likely to be linked to. You can also skip shipping a Markdown renderer this way!

Re: Git without a forge

#164

Post by cxr » Sun, Mar 09, 2025, 1:01 PM UTC

Ferret7446 wrote: post #162

satvikpendem wrote: post #149

Earlier quoted context omitted.

> Two factor authentication, I'm sure you can google it. The question was rhetorical, they are showing how a passkey is also a form of 2FA.

It's not, though. The passkey itself is strictly a single factor. That's kinda the point, to reduce user toil. Your passkey could have 2FA locally (e.g., a Yubikey with a PIN), but that is up to your discretion. It may be single factor.

> It's not, though. The passkey itself is strictly a single factor.

The passkey alone is not sufficient to log in. You must also provide a successful response to the WebAuthn challenge from an authenticator that has been registered/configured with that passkey.

> That's kinda the point, to reduce user toil.

It's almost as if letting people elect to enter their secure, never-written-down-anywhere-else passphrase would accomplish that.