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

• JamesLeonis

  today at 12:35 AM

  I like this idea quite a bit. It's lightweight and read-only, which makes it far easier to host. I'm in the process of publishing some of my own repositories so I'm going to give this a try.

• johannes1234321

  yesterday at 10:50 PM

  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?

  • dgl

    today at 2:56 AM

    Getting the tree (at the root) is only a few requests (get the refs or HEAD, get the relevant commit, get the tree ID from that). If pack files aren't involved then that's literally 3 requests. Pack files make this more complex, but careful caching and range requests could reduce that to as few as around 5-8 extra requests (doing binary searching via HTTP range requests). I don't think even libgit2 has APIs for range requests on pack files though, so this would need a special library (or patching libgit2...).

    There's also various optimizations on the git side like bitmaps[1] and commit-graphs[2]. If this a bare repo on the server side it shouldn't be a problem to make sure it is in a particular format with receive hooks.

    That's just displaying a file listing though. Displaying what GitHub displays with the last change of each file is more complex, maybe the commit graph could be used so the client wouldn't have to fetch everything itself.

      [1]: https://git-scm.com/docs/bitmap-format
      [2]: https://git-scm.com/docs/commit-graph

  • sneak

    today at 12:36 AM

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

    • jarofgreen

      today at 6:37 AM

      https://git.trevorbentley.com/itsy-gitsy/ (I don't use so not sure how good it is, just noting)

    • nhanb

      today at 1:34 AM

      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.

      • mikepurvis

        today at 2:25 AM

        That does get intense pretty quickly, if you're generating a source and commit/diff pages for every file * every commit. Probably just single commits would make the most sense and then a source browser for each branch.

        That said, JavaScript libgit2 is a thing [1], so doing it "properly" in a client app is totally possible.

        [1]: https://github.com/libgit2/libgit2/issues/4376 | https://github.com/petersalomonsen/wasm-git

        • notpushkin

          today at 4:46 AM

          I’d go with a combined approach. Static pages for every file on master, JS for everything else. This way master branch loads instantly, but other branches (with diff, blame etc) are also available.

          Hmmm, I might give it a go one day.

          • mikepurvis

            today at 5:35 AM

            Would the js pages really take much longer to load than static? Fetching a few packfiles and hydrating a template should be very fast.

            • notpushkin

              today at 7:42 AM

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

              Of course, there’s also the argument that if you’re self-hosting a repo, you’re more likely to care about users that have disabled JS (which is a good idea, tbh).

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

• AceJohnny2

  today at 2:07 AM

  (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

    today at 2:27 AM

    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

    today at 2:47 AM

    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.

• system33-

  yesterday at 11:42 PM

  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

    today at 1:08 AM

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

    • yellowapple

      today at 2:22 AM

      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'

      - 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

        today at 3:04 AM

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

          today at 5:43 AM

          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

    • ndegruchy

      today at 1:29 AM

      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

• yellowapple

  today at 2:04 AM

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

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

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/

[1] https://git-am.io/

[2] https://git-scm.com/docs/git-format-patch#Documentation/git-...

• bjackman

  yesterday at 10:00 PM

  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.

  • karel-3d

    today at 8:57 AM

    The other guy got downvoted, but... isn't there really some tooling to help with this? Some standardized way of actually sending/reviewing the e-mails?

    sourcehut has some GUI around it (that I never actually used). I heard that there is some local terminal thing around the e-mail git flow...?

    One thing I like - in theory - is how decentralized/federated it all is. E-mail is the original decentralization/federation! But I never had to actually use it.

  • imiric

    today at 12:33 AM

    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.

    • JoshTriplett

      today at 12:38 AM

      > Surely a project the size of Linux, for which Git was originally created, would arrive at a workflow that is optimal for most contributors.

      No, it really, really wouldn't. The Linux workflow is optimized for the preferences of (a subset of) maintainers, notably Linus; it is not optimized for contributors.

• cortesoft

  today at 5:47 AM

  I think it is funny to think of the email-driven git workflow as 'traditional' when it had such a short period of time as the standard way of doing things with git.

  Git was created in 2005, and Github was created in 2008. So we had 3 years of email-driven git and 17 years of Github style development.

  • PhilipRoman

    today at 6:55 AM

    Patches were being mailed long before that, since they work perfectly fine without Git.

• sneak

  today at 12:38 AM

  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.

  • bigstrat2003

    today at 12:43 AM

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

  • TylerE

    today at 7:46 AM

    See, I don't think it has much to do with not being on "the web" and everything to do with federated services actually being a terrible fit for most users most of the time, and not worth the headaches (e.g. spam, netsplits, missing posts...)

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

• q0uaur

  today at 12:40 AM

  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.

• kazinator

  today at 2:15 AM

  > requiring signing up to a mailing list

  A traditionally configured mailing list allows posts from non-subscribers.

  All the mailing lists I operate are like this.

  If you have good anti-spam-fu, you can get away with it. Plus, it's possible to have posts from non-members be held for moderation, and you can whitelist non-members who write legitimate posts.

  Projects which require people to sign up to their mailing lists to participate are erecting a barrier that costs them users; it's a stupid thing to do, and unnecessary.

  Whenever I have to interact with some mailing list, I begin by just sending my query to the list address. If it bounces due to nonmembership, I usually move on, unless it's some important matter.

  By the way, some modern lists allow posts from non-members but then rewrite the headers in such a way that the nonmember does not receive replies! This happens in more than one way, I think. One of them is Reply-To Munging: the list robot sets the Reply-To: header redirecting replies to be directed to the list address. The Reply-To throws away the content of the original To and Cc fields.

  When this happens to me, I usually refrain from further interaction with the list. I check for replies in their archive. If I'm satisfied with what they said, that's the end of it.

• devnullbrain

  yesterday at 10:52 PM

  >when he freely admits his process is incomprehensible.

  Which one of the 4 preferred processes, not including the maligned git send-email, and infinite other accepted processes?

• Brian_K_White

  yesterday at 10:24 PM

  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

    today at 8:08 AM

    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.

> 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

  today at 9:01 AM

  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.

> 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

  today at 12:25 AM

  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

    today at 12:54 AM

    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

    today at 12:55 AM

    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

  • mauricioc

    today at 7:23 AM

    > Of course, the classic response is "get a better MUA you luser"

    Git is distributed and allows you to work efficiently with poor connectivity, having full history available at any time, which is a big accessibility point for people with limited connectivity (and also helps people working while traveling, for example). If you do have any email client, you get all of this as well, plus arbitrarily powerful, low-latency filtering and searching. I recommend Greg KH's "Patches carved into stone tablets" talk [0].

    Despite your "luser" strawman, people advocating for client-side MUAs mean well and have a point. Try replacing "webmail" by "Notepad" and "client-side MUA" by "emacs/vim" to see how your argument sounds. You probably spend a decent amount of time interacting with email, and the investment in setting up a fast, flexible and powerful environment (preferably reusing your text editor for composing messages) for doing so pays for itself soon.

    [0] https://www.youtube.com/watch?v=L8OOzaqS37s

• layer8

  today at 12:25 AM

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

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.

• jeroenhd

  today at 8:12 AM

  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.

• _flux

  today at 7:46 AM

  Well, there's https://radicle.xyz/ but it doesn't seem too popular—that is, I've never seen a project that is hosted on it.

• sneak

  today at 12:36 AM

  Gitea is a foss clone of GitHub that is implementing federation features. It’s absolutely excellent.

  • duskwuff

    today at 6:01 AM

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

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

• neilv

  today at 1:03 AM

  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.

> 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

  yesterday at 10:10 PM

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

  • kelnos

    today at 3:35 AM

    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

      today at 4:58 AM

      The only way to do it is disable registration and have people contact you to allow registration.

      • Svenstaro

        today at 6:17 AM

        We do this in Arch Linux. It requires someone handling the registrations which isn't great either.

    • aitchnyu

      today at 6:39 AM

      Umm, why does a spammer bother with getting a Gitlab account in the first place?

      • da_chicken

        today at 8:58 AM

        Because it's $0 access to eyeballs.

  • ambigious7777

    yesterday at 11:23 PM

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

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

• spudlyo

  today at 1:29 AM

  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.

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.

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_

  today at 2:41 AM

  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

  today at 4:43 AM

  Yes, I've found Gitea very easy to self-host as well (I have two instances facing the public internet at the moment).

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

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

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

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__

  today at 8:02 AM

  He's got a whole "Why" section.

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.

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.

There are radicle.xyz and tangled.sh .

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.

• kelnos

  today at 3:40 AM

  > but the "need to create an account" is an extremely valid drawback, and one I do not have a good answer to.

  I never find this to be a big deal. The friction to create a new account is usually pretty low. Type in my email address, let Firefox generate and save a secure password, maybe do email verification, and I'm in. If I'm willing to spend possibly hours crafting a patch to contribute to some software I like, followed by some code-review back-and-forth, the few minutes spent setting up an account is nothing.

• LadyCailin

  yesterday at 11:26 PM

  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.

  • npodbielski

    today at 8:01 AM

    I am running my own email server for several years and most of the services on the internet are happily integrate with it. The only times I think I had some sort of the problem was small companies with incorrectly configured exchange that was refusing to deliver my messages.

  • zem

    yesterday at 11:38 PM

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

    • andyferris

      today at 12:35 AM

      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.

      • kelnos

        today at 3:41 AM

        I refuse to use those, because that means now my ability to log into this website is tied to my ability to log into the identity provider's website. I'd rather maintain control over that myself.

      • 418tpot

        today at 2:28 AM

        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.

  • spudlyo

    today at 1:32 AM

    Can one be a full fledged netizen sans email account?

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

• makapuf

  yesterday at 10:23 PM

  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.

• fiddlerwoaroof

  yesterday at 10:21 PM

  Bundles only include things that can be in the pack files: the git objects `git clone` would pull.

• Joker_vD

  today at 12:20 AM

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

  • cryptonector

    today at 3:06 AM

    Does it cause problems on mobile or something?

  • throw94040

    today at 5:05 AM

    That was on my android keyboard.

• keybored

  today at 4:20 AM

  git bundle works like git clone so there's nothing to worry about.

  You simply don't know what you are talking about.

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.

I did not know about git bundle, thank you.

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

  today at 12:38 AM

  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

  today at 12:38 AM

  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.

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.

[dead]

[flagged]

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.

• dspillett

  today at 9:06 AM

  > 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

  today at 9:16 AM

  People who can't grok email aren't making useful changes to PuTTY

• DJHenk

  today at 7:33 AM

  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.

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

• __MatrixMan__

  today at 8:08 AM

  Being popular makes something a high value target. I think it's quite reasonable to have a threat model which avoids such things.

• kelnos

  today at 3:42 AM

  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

    today at 7:34 AM

    > monocultures are bad, and doesn't want to support them

    is just

    > it's popular, it must be eschewed.

    after a chatgpt pass