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

21–30 of 164 posts

Re: Git without a forge

#21

Post by ambigious7777 »

rglullis wrote: post #11
etaweb wrote: post #7

> In particular, your project automatically gets a bug tracker – and you don’t get a choice about what bug tracker to use, or what it looks like. If you use Gitlab, you’re using the Gitlab bug tracker. The same goes for the pull request / merge request system. With Forgejo (Codeberg) you can toggle features such as pull requests, issues, etc. You can also configure any external issue tracker or wiki apparently, thoug…

Forgejo (once federation is implemented) also fixes the main issue of forcing people to have an account at every forge.

I do hope that Forgejo Federation is implemented, but it seems to me progress has stalled on it?

Re: Git without a forge

#22

Post by LadyCailin »

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.

Re: Git without a forge

#23

Post by zem »

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.

yes, but people have an email account already. if they could use that to interact with my git forge that would be ideal.

Re: Git without a forge

#24

Post by system33- »

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.

Re: Git without a forge

#25

Post by rlpb »

> 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 then I have to save them one by one to files, and manually sort those files back into the right order by their subject lines.

The patch series arrives threaded, so your MUA should be able to display them in order. Export them to an mbox file, and then use `git am` again.

There might be ways that someone can send you email in this way and for the patches to be broken such that `git am` won’t work, of course. I take no issue with that part of the argument.

Re: Git without a forge

#27

Post by oneplane »

I wonder if (especially after finishing the bottom part of the article) a mailing list type of interaction, but with Git, is exactly the sort of "in the open" version that is described as a potential improvement.

I'm not sure to what degree that natively allows for integration between Git and an MTA but it would still have most of the desired aspects.

Re: Git without a forge

#28

Post by Joker_vD »

throw94040 wrote: post #10

》The simplest kind of git bundle – a full bundle – is a whole git repository, wrapped up into a single file. Git repo can have executable code! Git hooks are shell commands stored in dir ".git/hooks" executed on events such as merge, commit... That is not duplicated by git clone, I am not sure about bundles. But I would be VERY careful to accept something like compressed git repo from anyone!

Sorry, did you have to use a Wide character? There is a Narrow version of it: ⟫ U+27EB MATHEMATICAL RIGHT DOUBLE ANGLE BRACKET.

Re: Git without a forge

#29

Post by LegionMammal978 »

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", but that just adds even more steps for people who use webmail services for 99.9% of their email needs.

Re: Git without a forge

#30

Post by layer8 »

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…

Yes, this all stands and falls with using a competent email client. There are some hints regarding email clients here, though focused on sending patches: https://github.com/torvalds/linux/blob/master/Documentation/...
Post reply on HN