Git without a forge
chiark.greenend.org.uk
Git without a forge
1–10 of 164 posts
Re: Git without a forge
#2This 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 pushing.
All by the same people who make SQLite, Pikchr, and more.
Re: Git without a forge
#3For some context, Simon is the maintainer of PuTTY, as well as various other cool bits of software.
Re: Git without a forge
#4This 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 seems to work smoothly for the Linux kernel folks; clearly it doesn't have to be clunky.
> because git format-patch doesn’t mention what commit the patches do apply against, I’m more likely to encounter a conflict in the first place when trying to apply them.
This is what the --base flag is for. [2]
[0] https://git-send-email.io/
[2] https://git-scm.com/docs/git-format-patch#Documentation/git-...
Re: Git without a forge
#5[flagged]
Re: Git without a forge
#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 process is incomprehensible.
I don't buy the GitHub locks you in either. It's pretty easy to copy issues and releases elsewhere if it really comes to it. Or use Gitlab or Codeberg if you must.
https://docs.codeberg.org/advanced/migrating-repos/
Any of those are far better than random mailing lists, bugzilla, and emailed patch files.
Putty is great but please don't listen to this.
Re: Git without a forge
#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, though I've never tried it, because those included with the forge are good enough for me.
Re: Git without a forge
#8The way he prefers patches to him being sent (git repo URL + branch name) is basically what a forge does. Why make it more complicated for your users?
Re: Git without a forge
#9This 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 deal with (and mail servers? Fuck). Raw text with no concept of "review thread resolved" wastes loads of review energy manually tracking what feedback has or hasn't been addressed. Comparing old and new versions of a patchset (equivalent of a pull request) requires manually searching your mailbox for the different versions, manually applying them to your local repo (hopefully you can find the base commit the old version applies to, which by now might not even exist any more if it's an unstable maintainer branch) and then manually running git-range-diff.
As someone who works with an git-send-email workflow every day, I can tell you, it sucks. Email is not a good substrate for development.
If I were Linus I would be pestering the Linux Foundation to set up a bunch of managed Gerrit instances or something.
Re: Git without a forge
#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!