14 ms·

Git without a forge

322 points by todsacerdoti 2y ago

ndegruchy 2y ago
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 pushing. All by the same people who make SQLite, Pikchr, and more. [1]: https://fossil-scm.org https://fossil-scm.org
- system33- 2y ago
  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.
  - Lyngbakr 2y ago
    In terms of everyday workflow, does Fossil differ radically from git? If so, what's the learning curve like?
    - ndegruchy 2y ago
      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 https://fossil-scm.org/home/doc/trunk/www/gitusers.md
    - yellowapple 2y ago
      The biggest workflow differences I've noticed: - The repo normally lives outside of the worktree, so remembering to 'fossil new foo.fossil && mkdir foo && cd foo && fossil open ../foo.fossil' took some getting used to. Easy enough to throw into some 'fossil-bootstrap' script in my ~/.local/bin to never have to remember again. - For published repos, I've gotten in the habit of creating them directly on my webserver and then pulling 'em down with 'fossil clone https://${FOSSIL_USER}@fsl.yellowapple.us/foo https://${FOSSIL_USER}@fsl.yellowapple.us/foo' - The "Fossil way" is to automatically push and pull ("auto-sync") whenever you commit. It feels scary coming from Git, but now that I'm used to it I find it nice that I don't have to remember to separately push things; I just 'fossil ci -m "some message"' and it's automatically pushed. I don't even need to explicitly stage modified files (only newly-created ones), because... - Fossil automatically stages changed files for the next commit - which is a nice time-saver in 99% of cases where I do want to commit all of my changes, but is a slight inconvenience for the 1% of cases where I want to split the changes into separate commits. Easy enough to do, though, via e.g. 'fossil ci -m "first change" foo.txt bar.txt && fossil ci -m "everything else"'. - 'fossil status' doesn't default to showing untracked files like 'git status' does; 'fossil status --differ' is a closer equivalent.
      - chungy 2y ago
        > - Fossil automatically stages changed files for the next commit - which is a nice time-saver in 99% of cases where I do want to commit all of my changes, but is a slight inconvenience for the 1% of cases where I want to split the changes into separate commits. Easy enough to do, though, via e.g. 'fossil ci -m "first change" foo.txt bar.txt && fossil ci -m "everything else"'. That'd be a deal breaker for me. Git's staging area is such a breath of fresh air compared to the old way (that fossil is doing), that it's one of the biggest reasons for me to switch to it. It's completely freeing to not have to worry about things being accidentally added to commits that I didn't want to have.
        cortesoft 2y ago
        I agree, and adding a `-a` to your git commit if you dont want to have to add all the changes is not much of an added burden for people who operate in the fossil way
        Borg3 2y ago
        Not to mention this is kinda yet another hidden local version :) I have a habbit to do git add -u when stuff I work on is in good state and I am about to try something more risky. I just stage the stuff, and keep hacking. If I fuck it up.. I can git checkout files or everything up to a stage.
- yellowapple 2y ago
  That's exactly why I've been using Fossil exclusively for new projects, and have been (very slowly) migrating existing ones over as well. It ain't like my FOSS projects get a whole lot of outside contributions anyway (though I've been tinkering a bit with bidirectional Git syncs so that people can submit GitHub PRs / GitLab MRs / generic Git bundles / etc. in those rare cases).
- AceJohnny2 2y ago
  (tongue-in-cheek:) This is what I hate about Fossil, you get all this extra cruft (wiki, chat, forums, bug tracker) that's a worse version than dedicated software for each. It really depends on what you're optimizing for.
  - yellowapple 2y ago
    Thankfully, there's not much forcing you to use much of it; the "template repo" I use outright disables forum/wiki/chat/bugtracker access to non-admin users (i.e. anyone who hasn't cracked my password), since most of the time when I throw code out into the world I don't really care all that much about supporting it - and in the cases where I do care, I can always re-enable exactly the things I want.
  - ndegruchy 2y ago
    Fair enough. I usually deny permissions to the features I don't care about if I'm pushing it up on the web. It's nice to have them there if I need them, though.
- lordgroff 2y ago
  If Fossil let me rebase, I'd never use git for personal projects again. I love the whole all-in-one approach and it's all so functional. But the (almost extreme) hostility to a rebase workflow makes it a no go for me, and I'm sure many others.
AndrewDucker 2y ago
For some context, Simon is the maintainer of PuTTY, as well as various other cool bits of software.
- spudlyo 2y ago
  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.
MaxBarraclough 2y ago
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 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/ https://git-send-email.io/ [1] https://git-am.io/ https://git-am.io/ [2] https://git-scm.com/docs/git-format-patch#Documentation/git-format-patch.txt---no-baseltcommitgt https://git-scm.com/docs/git-format-patch#Documentation/git-...
- bjackman 2y ago
  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.
  - imiric 2y ago
    Don't they have tooling to help with these issues? Surely a project the size of Linux, for which Git was originally created, would arrive at a workflow that is optimal for most contributors. This won't align with everyone's preferences, of course, but I can't imagine someone like Linus not being happy with it.
fsdkfdsf 2y ago
[flagged]
IshKebab 2y ago
> 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/ 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.
- Brian_K_White 2y ago
  I submitted at least one patch to putty some time ago and it was such a nothingburger I don't even remember what it took. Somehow it neither baffled nor infuriated nor even annoyed me a little. All these complaints and critiques sound like so much baby crying over nothing to me.
  - jeroenhd 2y ago
    Same with the account creation on normal git websites. You fill out three fields and click a link in your email, it's no more complex than git send-email. I'm sure I can figure out the archaic git email system, how hard can it possibly be? Same with the git bundle thing, this is the first time I've read about it but it seems usable. I don't expect anyone I'll ever directly work with to know what the hell a bundle file is but if a project wants their git commits in that format, it shouldn't be that much of a problem. The biggest hurdle will probably be spam filters, but that's an email problem and not necessarily a git problem. Or course the downside to all this funky command line stuff is that you're applying a filter on the people who will ever contribute code. Plenty of people don't want to figure out the git's many weird command line flows and communication options. Plenty of developers don't care enough to actually learn about git beyond push/pull/rebase/merge. If you're only interested in the turbo nerds who enjoy using the many tricks git has to offer, you'll probably filter out most contributors, but realistically how many contributors does hobby project on a personal git server ever attract in the first place.
etaweb 2y ago
> 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.
- rglullis 2y ago
  Forgejo (once federation is implemented) also fixes the main issue of forcing people to have an account at every forge.
  - ambigious7777 2y ago
    I do hope that Forgejo Federation is implemented, but it seems to me progress has stalled on it?
  - kelnos 2y ago
    It does solve that problem, but then creates a huge spam problem. Over at gitlab.xfce.org we are constantly fighting new spam accounts that get created daily. We've done all the recommended/paranoid things, like not allowing new accounts to fork or create repos until we manually give them permission (among other things), and we have a script that runs hourly to shut down suspicious accounts. But it's still nuts. If anyone with an account on any other gitlab instance could automatically do things on our gitlab instance, it would be a nightmare. We'd probably disable federation if gitlab offered it.
    - pabs3 2y ago
      The only way to do it is disable registration and have people contact you to allow registration.
      - Svenstaro 2y ago
adastra22 2y ago
The 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?
- imiric 2y ago
  What's complicated about sending an email with the repo URL? The author concedes that just because they don't use a forge, it doesn't mean the contributors shouldn't.
- bigstrat2003 2y ago
  Why should it matter what potential contributors might want the workflow to be, unless his goal is to maximize contributors? There's nothing wrong with prioritizing your own tools desires, as long as you accept that it might limit how many people want to get involved.
  - adastra22 2y ago
    What I’m saying is that his own preferred workflow is the same. When you make a pull request, it shoots the maintainer an email with a link to the git branch. Literally the same thing.
throw94040 2y ago
》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!
- fiddlerwoaroof 2y ago
  Bundles only include things that can be in the pack files: the git objects `git clone` would pull.
- makapuf 2y ago
  As you said, git clone wont copy it, and you don't get a zip of a repo, you get a remote that you can clone/ pull from.
- Joker_vD 2y ago
  Sorry, did you have to use a Wide character? There is a Narrow version of it: ⟫ U+27EB MATHEMATICAL RIGHT DOUBLE ANGLE BRACKET.
  - cryptonector 2y ago
    Does it cause problems on mobile or something?
    - Joker_vD 2y ago
      Well, no, I've just spent some time recently on wrangling narrow and wide characters in the terminal emulators (and fonts they use) and I guess I am now somewhat more sensitive to the suspiciously looking whitespace. Do you know that, for instance, that the playing card symbols in the Unicode are narrow characters, the terminal emulators treat them so yet the fonts draw them as 1.5-cells wide which causes ugly and annoying overlaps?
      - 2y ago
zem 2y ago
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.
- LadyCailin 2y ago
  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.
  - zem 2y ago
    yes, but people have an email account already. if they could use that to interact with my git forge that would be ideal.
    - andyferris 2y ago
      These days most every website has "log in with Google", "log in with Apple", "log in with Microsoft", etc which sort-of addresses the issue (ironically to this comment, "log in with GitHub" is also pretty common). A more generic federated identity system that everyone could use/operate would of course be 1000% better. But slightly orthogonal to forge/no forge.
      - 418tpot 2y ago
        I don't think it really addresses the issue because it still requires an account at one of the predetermined identity providers. With email I just need a domain and I can self host the rest if I really cared to. It would be so much nicer if there was a federated way where I the user could specify any OAuth identity provider (even if it was e.g. a self hosted one) rather than the predetermined list dictated by the relying party. Funnily enough someone recently asked me if I could comment on a Product Hunt post and I was unable to do so since they only allow sign in with Google, Twitter, Facebook, Apple or Linked in; I have none of these accounts and would rather not create any of them. Oh well.
aard 2y ago
I very much support this sentiment! If we want a decentralized internet, we need to stop relying on large companies to manage everything for us. Git was designed to be a p2p system, but we very quickly centralized it with forges like Github. It is very discouraging. Most of the internet is like this now--managed by a handful of very powerful organizations. There is no end to the problems this will cause.
- sneak 2y ago
  Gitea is a foss clone of GitHub that is implementing federation features. It’s absolutely excellent.
  - duskwuff 2y ago
    One thing which is particularly excellent about Gitea (and its fork, forgejo) is that it's quite lightweight for what it does. It's a single-process Go application with low memory requirements, and it can use a SQLite database (so you don't need a separate database server).
- _flux 2y ago
  Well, there's https://radicle.xyz/ https://radicle.xyz/ but it doesn't seem too popular—that is, I've never seen a project that is hosted on it.
- jeroenhd 2y ago
  There are so many private hosting options for forges at this point that I don't buy the Github excuse anymore. Anyone who actually cares about decentralization can set up a Gitea/Gitlab server (or one of their forks) or use one of the many public alternative code forges. It's also quite common for projects to have read-only copies of their code on Github, where people can easily find them, with links to their real upstream in the README. These days, Git forges left and right are even working on decentralizing things like issues and comments, something Git doesn't track or care about. People flock to Github because it's free and easy. Very few people care about the peer-to-peer internet and decentralization that Git was built for.
wahern 2y ago
> People can ‘git clone’ my code, and there’s a web-based browsing interface (the basic gitweb) for looking around without having to clone it at all. I host my own public Git repositories, but statically--read-only, no HTML views. I don't want to run any specialized server-side code, whether dynamic or preprocessed, as that's a security vector and system administration maintenance headache I don't want to deal with. You can host a Git repository as a set of static files using any web server, without any special configuration. Just clone a bare repo into an existing visible directory. `git update-server-info` generates the necessary index files for `git clone https:// https://...` to work transparently. I add a post-receive hook to my read-write Git repositories that does `cd /path/to/mirror.git && git fetch && git --bare update-server-info` to keep the public repo updated. In theory something like gitweb could be implemented purely client-side, using JavaScript or WASM to fetch the Git indices and packs on-demand and generate the HTML views. Some day I'd like to give that a try if someone doesn't beat me to it. You could even serve it as index.html from the Git repository directory, so the browser app and the Git clone URL are identical.
- johannes1234321 2y ago
  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?
  - sneak 2y ago
    You could write a static site generator to generate a website from the repo, so you’re still just serving static files.
    - nhanb 2y ago
      I once explored doing just that: https://github.com/nhanb/boast 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.
paulddraper 2y ago
I was expecting the justification to be a stodgy get of my lawn rant. But the author does a very good and reasonable job of explaining it. It didn't convince me to do the same thing, but I can't help but nod along to the even-handed pros and cons that he lays out.
rlpb 2y ago
> 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.
- LegionMammal978 2y ago
  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.
  - rlpb 2y ago
    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.
  - djha-skin 2y ago
    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 https://github.com/djha-skin/git-receive-mail
agf 2y ago
Gotta plug the Portable Puzzle Collection, by the same author as this post: https://www.chiark.greenend.org.uk/~sgtatham/puzzles/ https://www.chiark.greenend.org.uk/~sgtatham/puzzles/
- neilv 2y ago
  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.
  - neilv 2y ago
    I even included SGT's puzzle collection in a Linux distro that was optimized for small size (but the puzzles were important)! :) https://www.neilvandyke.org/lildeb/ https://www.neilvandyke.org/lildeb/
oneplane 2y ago
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.
ajross 2y ago
The security analysis in this piece is awful. Basically, author uses git because they don't trust "forges", then proceeds to discuss how a direct attack against the repository history is very hard but "not impossible"[1], while failing to recognize that the by-far-most-robust protection against such an attack is to push it to MORE repositories and MORE clones hosted by MORE entities and not keeping it secret on... your own piece of random hardware you probably got from Amazon. The rest of it is reasonable advice as far as it goes. Learn how to replicate patches between raw repositories as a good practice, as you'll want to be able to do that anyway. Don't lean too hard on the GitHub abstraction of a "Pull Request" as that won't match what kernel people want, etc... [1] Technically true, but in practice a ridiculous whopper.
haswell 2y ago
The author talks about the effort of hosting something more heavyweight like Gitlab. Having recently decided to self-host a Gitea instance, I was happy to find how ridiculously easy it is to get this up and running. I'm not hosting this on the public Internet, so maybe it's not a fair comparison, but thought it was worth mentioning that there are lighter/easier forge options than Gitlab.
- brutal_chaos_ 2y ago
  I do this as well. Act Runner is great, too, if you want CI. It can be finicky, but I'm running it on a Pi4, so not the best setup for that.
- bo1024 2y ago
  Yes, I've found Gitea very easy to self-host as well (I have two instances facing the public internet at the moment).
qudat 2y ago
On the topic of git send-email being the worst: I’ve been slowly working on an ssh app that would replace send-email along with some other ideas surrounding collaboration over at: https://github.com/picosh/git-pr https://github.com/picosh/git-pr
bhasi 2y ago
I did not know about git bundle, thank you.
edfletcher_t137 2y ago
> Also, I might as well come out and say this: one reason I don’t want to use Github is because it’s the most popular place to host your code. It's the goth subculture of software development! Because it's popular, it must be eschewed. Geez.
- kelnos 2y ago
  You conveniently left out the justification for that statement: because the author believes monocultures are bad, and doesn't want to support them. I think that's entirely reasonable, and characterizing it as "goth subculture" is dishonest.
  - tylersmith 2y ago
    > monocultures are bad, and doesn't want to support them is just > it's popular, it must be eschewed. after a chatgpt pass
    - freeopinion 2y ago
      Chatgpt can turn one into the other. But that doesn't mean they are the same thing. You are right to be mindful of the similarities. But it could be a mistake to be dismissive of the deeper thinking that might be behind the statement if it isn't just AI spew.
- __MatrixMan__ 2y ago
  Being popular makes something a high value target. I think it's quite reasonable to have a threat model which avoids such things.
throwaway984393 2y ago
[dead]
rurban 2y ago
With git bug I'm independent on any forge, accounts and workflows there. I sync my bugs from github, but can also sync it to gitlab or codeberg.
Aeolun 2y ago
The only thing I can ever think of while reading these things is: Why? What could possibly possess you to want to review and apply patches through email? The whole mentality is just utterly foreign to me.
- __MatrixMan__ 2y ago
  He's got a whole "Why" section.
- jlarcombe 2y ago
  the author explains his reasons in considerable detail in the article...
  - Aeolun 2y ago
    Not far enough up that I wasn’t put off reading any further before I got to it.
ackyshake 2y ago
> A particular thing I don’t like about git forge websites is the way they make you create an account. Exactly. I used to have a GitHub account but as soon as it got bought out by Microsoft, I was gone. I still refuse to create an account, even though there have been bugs I wanted to report or patches I wanted to contribute. Maybe some maintainers still have email addresses on their profile, many don't. Even if they do, I just don't get the motivation to email them. People like to complain about email a lot, but I enjoy different mailing lists for open source software. You could have discussions with other users of that software or keep track of development by following the "-devel" list. All you needed is something you already had—email. Sadly, they're becoming less popular. Even python moved to discourse which—dun dun dun—requires an account. grumble grumble I like SourceHut for many reasons—it's the fastest forge I've used, it's FOSS, doesn't try to copy the GitHub UI like every other Git forge these days. But by far the reason I love it is _because_ it doesn't require me creating an account to contribute. I think of it as gitweb, but nicer.
- mcherm 2y ago
  I am curious -- what is your concern about creating an account? Is it security? Privacy? The need to keep track of it?
  - immibis 2y ago
    My GitHub account is blocked because I refuse to give them my phone number or install their app. They refused a GDPR deletion request too.
    - mcherm 2y ago
      OK, that's a really solid reason. Thank you! For me, it suggests that someone like you might not mind creating an account on a system I run (because I allow anonymous account creation without anything at all although providing an email is encouraged).
  - ackyshake 2y ago
    Security/privacy yeah. I don't do business with Twitter/Facebook for the same reason. In the case of GitHub, if I want to contribute something, I am going to do it volitionally, knowing they will do whatever they want with it. Creating an account just locks you in, when the alternative exists or existed before. SourceHut proves this is possible. Why not allow non-accounts to contribute?
snthpy 2y ago
There are radicle.xyz and tangled.sh .
mellosouls 2y ago
The author is obviously entitled to whatever workflow he chooses to use, and he isn't proselytizing here, but by choosing to sidestep industry standards he is ultimately just putting obstacles in front of other coders who might like to contribute. Unless you're really into git and email, it's just tiresome and a time sink having to work all this out. Fwiw I've used putty in the past and appreciate his efforts, if not his obscurantist tendencies.
- DJHenk 2y ago
  The regular forges have just as many obstacles. You have to register an account, figure out whether the button you need is 'Pull Request' or 'Merge Request', and what the exact flow is. The only reason things appeared simple in the past is because of GitHub's monopoly. As soon as you want to get rid of that, life gets more complicated. That is just another tradeoff you have to make.
  - zoobab 2y ago
    Like: "You need a mobile phone number and a mobile subscription to receive an SMS to login."
- dspillett 2y ago
  > ultimately just putting obstacles in front of other coders who might like to contribute Saying it is just that after reading the full text seems rather reductive and unfair. That is certainly a likely side effect, of course. It may even be a desirable one, avoiding, or at least reducing, several classes of time wasting contributions (like the glut of single typo fixing pull requests that resulted from an ill-conceived contribution based competition a while back), especially for "open source but not open contribution" projects. Some projects are not wanting to optimise for the number of contributors above other considerations.
- windward 2y ago
  People who can't grok email aren't making useful changes to PuTTY
- zoobab 2y ago
npodbielski 2y ago
Interesting how author integrated devops side of his software. Main part why I am running whole GitLab suite for my own projects (like a mobile application for my home control) is to have automatic, build, test and deployment process. I really disliked i.e. pushing new artifacts for fdroid repo. Build can be very long and I do not plan to look at the command line progress for 30 minutes to make sure that it is ready to be pushed to release. I guess someone can automate this with some cron jobs or bash scripts, file watchers and etc. But moving it to new machine it so much trouble. With GL I can just make a backup and restore it on the other machine. With everything running in docker it is much easier to get the environment running. Or at least for me.
fitsumbelay 2y ago
I've been reminding myself aka procrastinating to self-host my repos for years until reading this post and spent a few minutes realizing just out how easily I could be interacting with my VPS' git service instead of github. obviously there's a long way to go but it's going to be a winning investment in terms of learnings and data ownership
GTonehour 2y ago
> How do you send your patch to the maintainer? You send the author an email. I understand the article thinks of occasional contributors outside of the project. For developers of your team (if any), I guess you could grant them SSH access to push, with git hooks enforcing your workflow (prevent direct commits to main, feature-* branches...).
dspillett 2y ago
> Sometimes people just can’t work out how to send me patches at all. This could actually be useful for "open source but not open contribution" situations. It avoids the thing where people seeing that nice easy pull request button as somehow giving them the right to expect their contribution to be accepted. "If you don't want contributors, why is it on [insert-forge-here] in the first place?" is a question I've seen asked in discussions about such things. Some people get personally insulted when their pull doesn't happen, even though the project states clearly ahead of time that this is how things are. Heck, some seem to be offended in advance that some hypothetical patch they might produce in future would be rejected.
- thallian 2y ago
  This is basically what I do. Gitea instance with closed registration. So far I did get three different people sending me emails with patches/contributions and all the interactions were quite nice. Of course the stuff I am doing is not well known and I do not advertise it anywhere, which is its own moat I'd say.
arichard123 2y ago
I ran a ssh server for a while to store git repositories. We had some with secrets in and I didn't want them on github. I needed to provide read only access and read write access for only some of the repos. I ended up with a bash script that configure system users and groups and permissions to do the job. It's here: https://github.com/artumi-richard/ssh-git-hosting https://github.com/artumi-richard/ssh-git-hosting I stopped using it years ago. It had the additional advantage of no artificial limits (file sizes etc).
chuckadams 2y ago
> If you can’t find a button on a website to submit a patch, how do you send your patch to the maintainer? You send the author an email. "Did you just tell me to go fuck myself?" "I believe I did, Bob."
robertlagrant 2y ago
> I get particularly annoyed when people demand I move to Github for this reason. “Everyone is on Github, get with the programme! Conform!” I’m actually less likely to do it because you said that. Ugh. I 100% agree. When people say things like "You have to be on GitHub because that's where the community is" I don't know what to say. Who cares? Is it really that hard to log into (or not) a different Git server? Do we really want to encourage this idea of community anyway, at a scale larger than an individual project?
LuciOfStars 2y ago
SourceHut seems to be mostly what they're looking for. :-P
deleted 2y ago
[deleted]
johntitorjr 2y ago
A great turnkey forge option is Forgejo in a docker container. I love how light weight this is though. https://forgejo.org/ https://forgejo.org/ It's crazy how many people today think git == github.

322 points by todsacerdoti 2y ago

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 pushing. All by the same people who make SQLite, Pikchr, and more. [1]: https://fossil-scm.org https://fossil-scm.org

system33- 2y ago
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.
- Lyngbakr 2y ago
  In terms of everyday workflow, does Fossil differ radically from git? If so, what's the learning curve like?
  - ndegruchy 2y ago
    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 https://fossil-scm.org/home/doc/trunk/www/gitusers.md
  - yellowapple 2y ago
    The biggest workflow differences I've noticed: - The repo normally lives outside of the worktree, so remembering to 'fossil new foo.fossil && mkdir foo && cd foo && fossil open ../foo.fossil' took some getting used to. Easy enough to throw into some 'fossil-bootstrap' script in my ~/.local/bin to never have to remember again. - For published repos, I've gotten in the habit of creating them directly on my webserver and then pulling 'em down with 'fossil clone https://${FOSSIL_USER}@fsl.yellowapple.us/foo https://${FOSSIL_USER}@fsl.yellowapple.us/foo' - The "Fossil way" is to automatically push and pull ("auto-sync") whenever you commit. It feels scary coming from Git, but now that I'm used to it I find it nice that I don't have to remember to separately push things; I just 'fossil ci -m "some message"' and it's automatically pushed. I don't even need to explicitly stage modified files (only newly-created ones), because... - Fossil automatically stages changed files for the next commit - which is a nice time-saver in 99% of cases where I do want to commit all of my changes, but is a slight inconvenience for the 1% of cases where I want to split the changes into separate commits. Easy enough to do, though, via e.g. 'fossil ci -m "first change" foo.txt bar.txt && fossil ci -m "everything else"'. - 'fossil status' doesn't default to showing untracked files like 'git status' does; 'fossil status --differ' is a closer equivalent.
    - chungy 2y ago
      > - Fossil automatically stages changed files for the next commit - which is a nice time-saver in 99% of cases where I do want to commit all of my changes, but is a slight inconvenience for the 1% of cases where I want to split the changes into separate commits. Easy enough to do, though, via e.g. 'fossil ci -m "first change" foo.txt bar.txt && fossil ci -m "everything else"'. That'd be a deal breaker for me. Git's staging area is such a breath of fresh air compared to the old way (that fossil is doing), that it's one of the biggest reasons for me to switch to it. It's completely freeing to not have to worry about things being accidentally added to commits that I didn't want to have.
      - cortesoft 2y ago
        I agree, and adding a `-a` to your git commit if you dont want to have to add all the changes is not much of an added burden for people who operate in the fossil way
      - Borg3 2y ago
        Not to mention this is kinda yet another hidden local version :) I have a habbit to do git add -u when stuff I work on is in good state and I am about to try something more risky. I just stage the stuff, and keep hacking. If I fuck it up.. I can git checkout files or everything up to a stage.
yellowapple 2y ago
That's exactly why I've been using Fossil exclusively for new projects, and have been (very slowly) migrating existing ones over as well. It ain't like my FOSS projects get a whole lot of outside contributions anyway (though I've been tinkering a bit with bidirectional Git syncs so that people can submit GitHub PRs / GitLab MRs / generic Git bundles / etc. in those rare cases).
AceJohnny2 2y ago
(tongue-in-cheek:) This is what I hate about Fossil, you get all this extra cruft (wiki, chat, forums, bug tracker) that's a worse version than dedicated software for each. It really depends on what you're optimizing for.
- yellowapple 2y ago
  Thankfully, there's not much forcing you to use much of it; the "template repo" I use outright disables forum/wiki/chat/bugtracker access to non-admin users (i.e. anyone who hasn't cracked my password), since most of the time when I throw code out into the world I don't really care all that much about supporting it - and in the cases where I do care, I can always re-enable exactly the things I want.
- ndegruchy 2y ago
  Fair enough. I usually deny permissions to the features I don't care about if I'm pushing it up on the web. It's nice to have them there if I need them, though.
lordgroff 2y ago
If Fossil let me rebase, I'd never use git for personal projects again. I love the whole all-in-one approach and it's all so functional. But the (almost extreme) hostility to a rebase workflow makes it a no go for me, and I'm sure many others.

AndrewDucker 2y ago

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

spudlyo 2y ago
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.

MaxBarraclough 2y ago

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 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/ https://git-send-email.io/ [1] https://git-am.io/ https://git-am.io/ [2] https://git-scm.com/docs/git-format-patch#Documentation/git-format-patch.txt---no-baseltcommitgt https://git-scm.com/docs/git-format-patch#Documentation/git-...

bjackman 2y ago
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.
- imiric 2y ago
  Don't they have tooling to help with these issues? Surely a project the size of Linux, for which Git was originally created, would arrive at a workflow that is optimal for most contributors. This won't align with everyone's preferences, of course, but I can't imagine someone like Linus not being happy with it.

fsdkfdsf 2y ago

[flagged]

IshKebab 2y ago

> 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/ 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.

Brian_K_White 2y ago
I submitted at least one patch to putty some time ago and it was such a nothingburger I don't even remember what it took. Somehow it neither baffled nor infuriated nor even annoyed me a little. All these complaints and critiques sound like so much baby crying over nothing to me.
- jeroenhd 2y ago
  Same with the account creation on normal git websites. You fill out three fields and click a link in your email, it's no more complex than git send-email. I'm sure I can figure out the archaic git email system, how hard can it possibly be? Same with the git bundle thing, this is the first time I've read about it but it seems usable. I don't expect anyone I'll ever directly work with to know what the hell a bundle file is but if a project wants their git commits in that format, it shouldn't be that much of a problem. The biggest hurdle will probably be spam filters, but that's an email problem and not necessarily a git problem. Or course the downside to all this funky command line stuff is that you're applying a filter on the people who will ever contribute code. Plenty of people don't want to figure out the git's many weird command line flows and communication options. Plenty of developers don't care enough to actually learn about git beyond push/pull/rebase/merge. If you're only interested in the turbo nerds who enjoy using the many tricks git has to offer, you'll probably filter out most contributors, but realistically how many contributors does hobby project on a personal git server ever attract in the first place.

etaweb 2y ago

> 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.

rglullis 2y ago
Forgejo (once federation is implemented) also fixes the main issue of forcing people to have an account at every forge.
- ambigious7777 2y ago
  I do hope that Forgejo Federation is implemented, but it seems to me progress has stalled on it?
- kelnos 2y ago
  It does solve that problem, but then creates a huge spam problem. Over at gitlab.xfce.org we are constantly fighting new spam accounts that get created daily. We've done all the recommended/paranoid things, like not allowing new accounts to fork or create repos until we manually give them permission (among other things), and we have a script that runs hourly to shut down suspicious accounts. But it's still nuts. If anyone with an account on any other gitlab instance could automatically do things on our gitlab instance, it would be a nightmare. We'd probably disable federation if gitlab offered it.
  - pabs3 2y ago
    The only way to do it is disable registration and have people contact you to allow registration.
    - Svenstaro 2y ago

adastra22 2y ago

The 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?

imiric 2y ago
What's complicated about sending an email with the repo URL? The author concedes that just because they don't use a forge, it doesn't mean the contributors shouldn't.
bigstrat2003 2y ago
Why should it matter what potential contributors might want the workflow to be, unless his goal is to maximize contributors? There's nothing wrong with prioritizing your own tools desires, as long as you accept that it might limit how many people want to get involved.
- adastra22 2y ago
  What I’m saying is that his own preferred workflow is the same. When you make a pull request, it shoots the maintainer an email with a link to the git branch. Literally the same thing.

throw94040 2y ago

》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!

fiddlerwoaroof 2y ago
Bundles only include things that can be in the pack files: the git objects `git clone` would pull.
makapuf 2y ago
As you said, git clone wont copy it, and you don't get a zip of a repo, you get a remote that you can clone/ pull from.
Joker_vD 2y ago
Sorry, did you have to use a Wide character? There is a Narrow version of it: ⟫ U+27EB MATHEMATICAL RIGHT DOUBLE ANGLE BRACKET.
- cryptonector 2y ago
  Does it cause problems on mobile or something?
  - Joker_vD 2y ago
    Well, no, I've just spent some time recently on wrangling narrow and wide characters in the terminal emulators (and fonts they use) and I guess I am now somewhat more sensitive to the suspiciously looking whitespace. Do you know that, for instance, that the playing card symbols in the Unicode are narrow characters, the terminal emulators treat them so yet the fonts draw them as 1.5-cells wide which causes ugly and annoying overlaps?
    - 2y ago

zem 2y ago

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.

LadyCailin 2y ago
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.
- zem 2y ago
  yes, but people have an email account already. if they could use that to interact with my git forge that would be ideal.
  - andyferris 2y ago
    These days most every website has "log in with Google", "log in with Apple", "log in with Microsoft", etc which sort-of addresses the issue (ironically to this comment, "log in with GitHub" is also pretty common). A more generic federated identity system that everyone could use/operate would of course be 1000% better. But slightly orthogonal to forge/no forge.
    - 418tpot 2y ago
      I don't think it really addresses the issue because it still requires an account at one of the predetermined identity providers. With email I just need a domain and I can self host the rest if I really cared to. It would be so much nicer if there was a federated way where I the user could specify any OAuth identity provider (even if it was e.g. a self hosted one) rather than the predetermined list dictated by the relying party. Funnily enough someone recently asked me if I could comment on a Product Hunt post and I was unable to do so since they only allow sign in with Google, Twitter, Facebook, Apple or Linked in; I have none of these accounts and would rather not create any of them. Oh well.

aard 2y ago

I very much support this sentiment! If we want a decentralized internet, we need to stop relying on large companies to manage everything for us. Git was designed to be a p2p system, but we very quickly centralized it with forges like Github. It is very discouraging. Most of the internet is like this now--managed by a handful of very powerful organizations. There is no end to the problems this will cause.

sneak 2y ago
Gitea is a foss clone of GitHub that is implementing federation features. It’s absolutely excellent.
- duskwuff 2y ago
  One thing which is particularly excellent about Gitea (and its fork, forgejo) is that it's quite lightweight for what it does. It's a single-process Go application with low memory requirements, and it can use a SQLite database (so you don't need a separate database server).
_flux 2y ago
Well, there's https://radicle.xyz/ https://radicle.xyz/ but it doesn't seem too popular—that is, I've never seen a project that is hosted on it.
jeroenhd 2y ago
There are so many private hosting options for forges at this point that I don't buy the Github excuse anymore. Anyone who actually cares about decentralization can set up a Gitea/Gitlab server (or one of their forks) or use one of the many public alternative code forges. It's also quite common for projects to have read-only copies of their code on Github, where people can easily find them, with links to their real upstream in the README. These days, Git forges left and right are even working on decentralizing things like issues and comments, something Git doesn't track or care about. People flock to Github because it's free and easy. Very few people care about the peer-to-peer internet and decentralization that Git was built for.

wahern 2y ago

> People can ‘git clone’ my code, and there’s a web-based browsing interface (the basic gitweb) for looking around without having to clone it at all. I host my own public Git repositories, but statically--read-only, no HTML views. I don't want to run any specialized server-side code, whether dynamic or preprocessed, as that's a security vector and system administration maintenance headache I don't want to deal with. You can host a Git repository as a set of static files using any web server, without any special configuration. Just clone a bare repo into an existing visible directory. `git update-server-info` generates the necessary index files for `git clone https:// https://...` to work transparently. I add a post-receive hook to my read-write Git repositories that does `cd /path/to/mirror.git && git fetch && git --bare update-server-info` to keep the public repo updated. In theory something like gitweb could be implemented purely client-side, using JavaScript or WASM to fetch the Git indices and packs on-demand and generate the HTML views. Some day I'd like to give that a try if someone doesn't beat me to it. You could even serve it as index.html from the Git repository directory, so the browser app and the Git clone URL are identical.

johannes1234321 2y ago
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?
- sneak 2y ago
  You could write a static site generator to generate a website from the repo, so you’re still just serving static files.
  - nhanb 2y ago
    I once explored doing just that: https://github.com/nhanb/boast 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.

paulddraper 2y ago

I was expecting the justification to be a stodgy get of my lawn rant. But the author does a very good and reasonable job of explaining it. It didn't convince me to do the same thing, but I can't help but nod along to the even-handed pros and cons that he lays out.

rlpb 2y ago

> 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.

LegionMammal978 2y ago
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.
- rlpb 2y ago
  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.
- djha-skin 2y ago
  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 https://github.com/djha-skin/git-receive-mail

agf 2y ago

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

neilv 2y ago
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.
- neilv 2y ago
  I even included SGT's puzzle collection in a Linux distro that was optimized for small size (but the puzzles were important)! :) https://www.neilvandyke.org/lildeb/ https://www.neilvandyke.org/lildeb/

oneplane 2y ago

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.

ajross 2y ago

The security analysis in this piece is awful. Basically, author uses git because they don't trust "forges", then proceeds to discuss how a direct attack against the repository history is very hard but "not impossible"[1], while failing to recognize that the by-far-most-robust protection against such an attack is to push it to MORE repositories and MORE clones hosted by MORE entities and not keeping it secret on... your own piece of random hardware you probably got from Amazon. The rest of it is reasonable advice as far as it goes. Learn how to replicate patches between raw repositories as a good practice, as you'll want to be able to do that anyway. Don't lean too hard on the GitHub abstraction of a "Pull Request" as that won't match what kernel people want, etc... [1] Technically true, but in practice a ridiculous whopper.

haswell 2y ago

The author talks about the effort of hosting something more heavyweight like Gitlab. Having recently decided to self-host a Gitea instance, I was happy to find how ridiculously easy it is to get this up and running. I'm not hosting this on the public Internet, so maybe it's not a fair comparison, but thought it was worth mentioning that there are lighter/easier forge options than Gitlab.

brutal_chaos_ 2y ago
I do this as well. Act Runner is great, too, if you want CI. It can be finicky, but I'm running it on a Pi4, so not the best setup for that.
bo1024 2y ago
Yes, I've found Gitea very easy to self-host as well (I have two instances facing the public internet at the moment).

qudat 2y ago

On the topic of git send-email being the worst: I’ve been slowly working on an ssh app that would replace send-email along with some other ideas surrounding collaboration over at: https://github.com/picosh/git-pr https://github.com/picosh/git-pr

bhasi 2y ago

I did not know about git bundle, thank you.

edfletcher_t137 2y ago

> Also, I might as well come out and say this: one reason I don’t want to use Github is because it’s the most popular place to host your code. It's the goth subculture of software development! Because it's popular, it must be eschewed. Geez.

kelnos 2y ago
You conveniently left out the justification for that statement: because the author believes monocultures are bad, and doesn't want to support them. I think that's entirely reasonable, and characterizing it as "goth subculture" is dishonest.
- tylersmith 2y ago
  > monocultures are bad, and doesn't want to support them is just > it's popular, it must be eschewed. after a chatgpt pass
  - freeopinion 2y ago
    Chatgpt can turn one into the other. But that doesn't mean they are the same thing. You are right to be mindful of the similarities. But it could be a mistake to be dismissive of the deeper thinking that might be behind the statement if it isn't just AI spew.
__MatrixMan__ 2y ago
Being popular makes something a high value target. I think it's quite reasonable to have a threat model which avoids such things.

throwaway984393 2y ago

[dead]

rurban 2y ago

With git bug I'm independent on any forge, accounts and workflows there. I sync my bugs from github, but can also sync it to gitlab or codeberg.

Aeolun 2y ago

The only thing I can ever think of while reading these things is: Why? What could possibly possess you to want to review and apply patches through email? The whole mentality is just utterly foreign to me.

__MatrixMan__ 2y ago
He's got a whole "Why" section.
jlarcombe 2y ago
the author explains his reasons in considerable detail in the article...
- Aeolun 2y ago
  Not far enough up that I wasn’t put off reading any further before I got to it.

ackyshake 2y ago

> A particular thing I don’t like about git forge websites is the way they make you create an account. Exactly. I used to have a GitHub account but as soon as it got bought out by Microsoft, I was gone. I still refuse to create an account, even though there have been bugs I wanted to report or patches I wanted to contribute. Maybe some maintainers still have email addresses on their profile, many don't. Even if they do, I just don't get the motivation to email them. People like to complain about email a lot, but I enjoy different mailing lists for open source software. You could have discussions with other users of that software or keep track of development by following the "-devel" list. All you needed is something you already had—email. Sadly, they're becoming less popular. Even python moved to discourse which—dun dun dun—requires an account. grumble grumble I like SourceHut for many reasons—it's the fastest forge I've used, it's FOSS, doesn't try to copy the GitHub UI like every other Git forge these days. But by far the reason I love it is _because_ it doesn't require me creating an account to contribute. I think of it as gitweb, but nicer.

mcherm 2y ago
I am curious -- what is your concern about creating an account? Is it security? Privacy? The need to keep track of it?
- immibis 2y ago
  My GitHub account is blocked because I refuse to give them my phone number or install their app. They refused a GDPR deletion request too.
  - mcherm 2y ago
    OK, that's a really solid reason. Thank you! For me, it suggests that someone like you might not mind creating an account on a system I run (because I allow anonymous account creation without anything at all although providing an email is encouraged).
- ackyshake 2y ago
  Security/privacy yeah. I don't do business with Twitter/Facebook for the same reason. In the case of GitHub, if I want to contribute something, I am going to do it volitionally, knowing they will do whatever they want with it. Creating an account just locks you in, when the alternative exists or existed before. SourceHut proves this is possible. Why not allow non-accounts to contribute?

snthpy 2y ago

There are radicle.xyz and tangled.sh .

mellosouls 2y ago

The author is obviously entitled to whatever workflow he chooses to use, and he isn't proselytizing here, but by choosing to sidestep industry standards he is ultimately just putting obstacles in front of other coders who might like to contribute. Unless you're really into git and email, it's just tiresome and a time sink having to work all this out. Fwiw I've used putty in the past and appreciate his efforts, if not his obscurantist tendencies.

DJHenk 2y ago
The regular forges have just as many obstacles. You have to register an account, figure out whether the button you need is 'Pull Request' or 'Merge Request', and what the exact flow is. The only reason things appeared simple in the past is because of GitHub's monopoly. As soon as you want to get rid of that, life gets more complicated. That is just another tradeoff you have to make.
- zoobab 2y ago
  Like: "You need a mobile phone number and a mobile subscription to receive an SMS to login."
dspillett 2y ago
> ultimately just putting obstacles in front of other coders who might like to contribute Saying it is just that after reading the full text seems rather reductive and unfair. That is certainly a likely side effect, of course. It may even be a desirable one, avoiding, or at least reducing, several classes of time wasting contributions (like the glut of single typo fixing pull requests that resulted from an ill-conceived contribution based competition a while back), especially for "open source but not open contribution" projects. Some projects are not wanting to optimise for the number of contributors above other considerations.
windward 2y ago
People who can't grok email aren't making useful changes to PuTTY
zoobab 2y ago

npodbielski 2y ago

Interesting how author integrated devops side of his software. Main part why I am running whole GitLab suite for my own projects (like a mobile application for my home control) is to have automatic, build, test and deployment process. I really disliked i.e. pushing new artifacts for fdroid repo. Build can be very long and I do not plan to look at the command line progress for 30 minutes to make sure that it is ready to be pushed to release. I guess someone can automate this with some cron jobs or bash scripts, file watchers and etc. But moving it to new machine it so much trouble. With GL I can just make a backup and restore it on the other machine. With everything running in docker it is much easier to get the environment running. Or at least for me.

fitsumbelay 2y ago

I've been reminding myself aka procrastinating to self-host my repos for years until reading this post and spent a few minutes realizing just out how easily I could be interacting with my VPS' git service instead of github. obviously there's a long way to go but it's going to be a winning investment in terms of learnings and data ownership

GTonehour 2y ago

> How do you send your patch to the maintainer? You send the author an email. I understand the article thinks of occasional contributors outside of the project. For developers of your team (if any), I guess you could grant them SSH access to push, with git hooks enforcing your workflow (prevent direct commits to main, feature-* branches...).

dspillett 2y ago

> Sometimes people just can’t work out how to send me patches at all. This could actually be useful for "open source but not open contribution" situations. It avoids the thing where people seeing that nice easy pull request button as somehow giving them the right to expect their contribution to be accepted. "If you don't want contributors, why is it on [insert-forge-here] in the first place?" is a question I've seen asked in discussions about such things. Some people get personally insulted when their pull doesn't happen, even though the project states clearly ahead of time that this is how things are. Heck, some seem to be offended in advance that some hypothetical patch they might produce in future would be rejected.

thallian 2y ago
This is basically what I do. Gitea instance with closed registration. So far I did get three different people sending me emails with patches/contributions and all the interactions were quite nice. Of course the stuff I am doing is not well known and I do not advertise it anywhere, which is its own moat I'd say.

arichard123 2y ago

I ran a ssh server for a while to store git repositories. We had some with secrets in and I didn't want them on github. I needed to provide read only access and read write access for only some of the repos. I ended up with a bash script that configure system users and groups and permissions to do the job. It's here: https://github.com/artumi-richard/ssh-git-hosting https://github.com/artumi-richard/ssh-git-hosting I stopped using it years ago. It had the additional advantage of no artificial limits (file sizes etc).

chuckadams 2y ago

> If you can’t find a button on a website to submit a patch, how do you send your patch to the maintainer? You send the author an email. "Did you just tell me to go fuck myself?" "I believe I did, Bob."

robertlagrant 2y ago

> I get particularly annoyed when people demand I move to Github for this reason. “Everyone is on Github, get with the programme! Conform!” I’m actually less likely to do it because you said that. Ugh. I 100% agree. When people say things like "You have to be on GitHub because that's where the community is" I don't know what to say. Who cares? Is it really that hard to log into (or not) a different Git server? Do we really want to encourage this idea of community anyway, at a scale larger than an individual project?

LuciOfStars 2y ago

SourceHut seems to be mostly what they're looking for. :-P

deleted 2y ago

[deleted]

johntitorjr 2y ago

A great turnkey forge option is Forgejo in a docker container. I love how light weight this is though. https://forgejo.org/ https://forgejo.org/ It's crazy how many people today think git == github.