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

Git without a forge

chiark.greenend.org.uk

Post reply on HN
Print view View original

41–50 of 164 posts

Re: Git without a forge

#41

Post by q0uaur »

IshKebab wrote: post #6

> Sometimes people just can’t work out how to send me patches at all. Yeah indeed. I have written but not submitted patches to a project (OpenSBI) because it made the submission process super complicated, requiring signing up to a mailing list, learning how to set up git send-email. I don't see how he can think creating a GitHub account (which almost everyone already has) is a big barrier when he freely admits his pr…

Back when i checked out sr.ht, i really liked the idea of git-send-email precisely because it doesn't require making an account for everything. there's a nice tutorial for how to set it up: https://git-send-email.io/#step-1

worked easily enough for me, i could see myself using it for small patches here and there.

I did end up installing forgejo in my homelab after all, but back then it sounded like federation was much closer than it actually was. i did kind of expect that though, federation gets pretty complex quick.

every time i log into forgejo, i do see that juicy "proceed with OpenID" button though, and i've looked into running my own openid provider a few times - sadly not seeing anything that would work for me yet. honestly i can't believe we went from "facebook sign in" to "google sign in" and are now going to "github sign in" without a single open standard that's gotten some adoption.

Re: Git without a forge

#42

Post by bigstrat2003 »

sneak wrote: post #38
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…

Email, like nntp and gopher, lost to the web. People won’t use it if it ain’t on the web. If you force them to use it anyway, very few people will use it. DdV’s advocacy stems from the fact that he is a lone-wolf dev, building tooling for other lone-wolf devs. The social and collaborative features sucking is a feature, not a bug. It falls flat on its face for larger projects and communities.

> If you force them to use it anyway, very few people will use it.

And that's perfectly fine. Not all things are for all people, and nor should they even try to be.

Re: Git without a forge

#43

Post by rlpb »

LegionMammal978 wrote: post #29
rlpb wrote: post #25

> Multiple files to herd. When I get an email with five patch attachments, I have five files to copy around instead of one, with long awkward names. That’s not correct. You can write the email to an mbox file (your MUA lets you do that, right?) and then use `git am` to pull it all into git. > Why I don’t like it: because the patch series is split into multiple emails, they arrive in my inbox in a random order, and th…

Not everyone has a fancy client-side MUA that gives them trivial access to mbox files. E.g., a typical webmail service will make exporting mboxes into a whole process at best. (And on the sending side, have fun with the lack of git send-email integration. I've spent far more time than I'd like manually patching up References and In-Reply-To headers.) Of course, the classic response is "get a better MUA you luser", bu…

People can use webmail for regular email, but then connect a “better” MUA for patch handling. I get that this would be more steps, but for those who don’t want to do this, they probably just use GitHub PRs, and that’s fine, they can carry on doing that :-)

I’m just completing the picture by pointing out that for those who choose to use emails to jockey patches around by mutual agreement, including patches in emails really shouldn’t be a problem.

Re: Git without a forge

#44

Post by djha-skin »

LegionMammal978 wrote: post #29
rlpb wrote: post #25

> Multiple files to herd. When I get an email with five patch attachments, I have five files to copy around instead of one, with long awkward names. That’s not correct. You can write the email to an mbox file (your MUA lets you do that, right?) and then use `git am` to pull it all into git. > Why I don’t like it: because the patch series is split into multiple emails, they arrive in my inbox in a random order, and th…

Not everyone has a fancy client-side MUA that gives them trivial access to mbox files. E.g., a typical webmail service will make exporting mboxes into a whole process at best. (And on the sending side, have fun with the lack of git send-email integration. I've spent far more time than I'd like manually patching up References and In-Reply-To headers.) Of course, the classic response is "get a better MUA you luser", bu…

For those that don't have an MUA, I have made git-receive-mail[1]. It really is very doable these days to do the email workflow, on both ends.

1: https://github.com/djha-skin/git-receive-mail

Re: Git without a forge

#45

Post by neilv »

agf wrote: post #26

Gotta plug the Portable Puzzle Collection, by the same author as this post: https://www.chiark.greenend.org.uk/~sgtatham/puzzles/

I can't tell you how many waiting rooms, grocery checkout lines, and delayed public transit that his puzzle collection gotten me through. On every handheld and laptop starting with the Symbian-based Nokia E61.

Re: Git without a forge

#46

Post by Lyngbakr »

system33- wrote: post #24
ndegruchy wrote: post #2

This is what I love about Fossil[1]. You get all of those extra tools (wiki, chat, forums, bug tracker) in the server that is also in the binary that you use to manage the repo. So, if you want to serve it, just `fossil server file.fossil` or serve a whole directory of them. Or, if you want, you can just `fossil ui` and muck around yourself, locally. The server supports SSH and HTTPS interactions for cloning and push…

Yup. +1 for fossil. I wanted an issue tracker that wasn’t text files in the repo. Lots of git-based things that were heavier (gitea and friends) or hackier than I wanted. Decided to finally try out fossil and I think it’s really really neat.

In terms of everyday workflow, does Fossil differ radically from git? If so, what's the learning curve like?

Re: Git without a forge

#47

Post by spudlyo »

AndrewDucker wrote: post #3

For some context, Simon is the maintainer of PuTTY, as well as various other cool bits of software.

He mentions in TFA that he had a bug tracker for PuTTY before git forges were a thing, one might have gotten this from context.

Re: Git without a forge

#48

Post by ndegruchy »

Lyngbakr wrote: post #46
system33- wrote: post #24

Earlier quoted context omitted.

Yup. +1 for fossil. I wanted an issue tracker that wasn’t text files in the repo. Lots of git-based things that were heavier (gitea and friends) or hackier than I wanted. Decided to finally try out fossil and I think it’s really really neat.

In terms of everyday workflow, does Fossil differ radically from git? If so, what's the learning curve like?

Not tremendously. You still commit, you still push and pull. There is a history and ignore options.

There is a guide written for Git users:

https://fossil-scm.org/home/doc/trunk/www/gitusers.md

Re: Git without a forge

#49

Post by spudlyo »

LadyCailin wrote: post #22
zem wrote: post #12

as someone who finds the whole forge interface a massive improvement in git collaboration workflow I was fully prepared to find the author's arguments against a lightweight self hosted forge unconvincing. but the "need to create an account" is an extremely valid drawback, and one I do not have a good answer to.

You need to create an email account, and you’ll be doing that through a big email provider, if you want your emails to get delivered anywhere.

Can one be a full fledged netizen sans email account?

Re: Git without a forge

#50

Post by nhanb »

sneak wrote: post #34
johannes1234321 wrote: post #19

Earlier quoted context omitted.

I haven't looked into mich details of gibt's packing, but for a big repo you probably don't want a client to download it all nor do a huge amount of http range requests for being able to show the summary page. You think that would work well or would this need at least some caching layer?

You could write a static site generator to generate a website from the repo, so you’re still just serving static files.

I once explored doing just that: https://github.com/nhanb/boast

However I never got around to finishing it, mainly because I couldn't decide on where to stop: should I also generate commits from all non-master branches etc.

I flirted with the idea of a browser-side repo viewer too, but re-implementing git packfile parsing in js didn't seem like something I'd want to spend my time on, so I moved on. Glad to see others pondering the same thing though.

Post reply on HN