• The clean way that the if/fi and do/od constructs embraced non-determinism still looks cleaner to me than the contemporary toolkits of various mainstream languages and frameworks.

Yeah, I think a lot of people have been anticipating this sort of thing since the acquisition. My previous company switched to gitlab a few years ago while I was still there because of it.

git --bare on Dropbox?

what would you want in a social network for git repos? I suspect Gitlab is also pushing pretty hard into AI

there is a model group, but generally gitlab is structured around business problems: handbook.gitlab.com/handbook/product/categories/#hierarchy

I'd love to see a desktop/web client that works with the package managers to browse git repos wherever they might be

only issue is issues/discussions/PR comments don't have any kind of common API to leverage

Mid and large orgs will do what they do and have the resources to deal with a lot. But for individuals and small (<10 people) orgs I suspect the future consists of a lot of mirroring. I like to collect codeforges, and you can see them in the mirrors and forks section of my repos. Any large place will eventually diverge from our values, and any small place is liable to go under or keel over under load. Just spread multiple URLs. Let people contribute in whatever codeforge they use, and use raw git to paper over disconnects. All I need from a codeforge is to support anonymous git clone.

Gitlab feels like roughly the same generation/cohort as github. Switching to it feels like frying pan to fire.

tangled.sh is also worth a look

Codeberg is awesome!

Good mega thread: jawns.club/@skyfaller/114989129643625908

Time for a mastodon for git hosting?

Kartik Agaram hah came here to post that! Yes, lots of appealing ideas in there.

@Scott forgefed.org has received grants in the past.

If you want the social-coding aspects of GitHub, rather than just hosting personal projects, then Codeberg looks like the best option right now. Hoping that Forĝejo will take off as a federated platform in the near future, because Codeberg is too small to take over GitHub's role.

If you really want git, those are reasonable suggestions, but in my mind, github is the only reason to use git - and jj looks like it makes it reasonable. If you just want a better version control, for small projects I recommend fossil-scm.org much more intuitive workflow. By the author of sqlite.

@Dave Mason But you just provided 2 other reasons to use git:

• For larger projects
• Because jj makes it reasonable

Personally as someone who has done a lot of small projects, I'm not convinced Fossil is better or more intuitive. It just replaces some opinions with other opinions. For example, it's ideologically opposed to amending even private history, and this makes developing on it feel more like a centralized version control system. A bunch of subtle distinctions will confuse someone used to say git cherrypick .

I've tried out every new SCM out there, so I don't want to rabbithole, but I approached Fossil in the usual way I do, with a gradual ramp from git over some period of time. And Fossil just doesn't support that well right now. If you are looking to transition from git it has to be an atomic big bang transition, because the git importer doesn't generate deterministic ids for commit hashes.

Fossil feels like Arch did 20 years ago: promising, but over-ideological. But it is a good choice for small and new projects.

The main advantage I see to Fossil is the integration of issue tracking in the repository. Which could of course be retro-fitted to git, and there are projects that do so, but... they are incompatible with the big forges.

One more reason to use git is the enormous tooling ecosystem it has accumulated. It's not just GitHub (though I agree that GitHub is what made git "win" over everyone else at the time). For me, it's magit, the Emacs git interface, which is by far the best UX for version control I have seen anywhere. I am not even interested in jj unless it gets magit integration one day.

My main issue with fossil is that each repo is completely isolated. I'd love to reuse my settings for every repo that I have.

Currently testing out radicle which seems promising.

I am also intrigued by Radicle and Tangled... I hope these projects with a decentralised flavor will continue to grow.

@Robin Heggelund Hansen Please share your experience with Radicle here!

@Robin Heggelund Hansen It does look like you can set settings to a whole device rather than a single repo using the -global commandline flag. Am I understanding you right?

Konrad Hinsen limited experience so far. I’m using it for a couple of repos, but I’m the only commiter.

I do like that it’s local first. I like that I can create issues and patches (PRs) from the command line.

The one thing I can currently imagine will be a problem is that you need to use a radicle client to add and comment on issues. It’s read-only in the browser (which makes sense, but…)

Kartik Agaram i was thinking about how issues are setup (labels, which columns are shown etc.) and users (each repo has it’s own set of users and permissions).

You can create a new repo using another as a template, but there’s no way to keep multiple repos in sync.

Thanks @Robin Heggelund Hansen! Requiring a locally installed client makes Radicle a developer-only tool. But then, I guess that's just the current state. I don't see anything about Radicle that would prevent putting the client into a browser for a wider public.

Konrad Hinsen since Radicle uses ssh keys for authentication/identification, I'm going to assume that it's never going to be as easy as logging in to a website to leave a comment.

the metaphor I think of is: we should have community pools in the US, there’s enough demand for large groups but it’s annoying and wasteful for individuals to maintain their own pools

(of course the answer to why we don’t have community pools is racism but let’s not get off track here, he says to himself)

like, what if there were an FoC infra group with waves hands towards a small funding goal that could manage a gitea/forgejo/whatever instance

I don’t know how that sort of group works, financially or socially, or how to put it together, but I want it!

The problem is partly that nobody understands the cost and efficiency characteristics of the community software we're all only recently starting to want to share. And we also keep developing new features, so lessons about cost keep getting obsoleted.

The ideal for society is not "free" as various idiots proclaimed in the 200x's and 201x's. The ideal is accurate and transparent cost models that are decoupled from a profit motive. Right now the only people able to reliably bill for usage are AWS and equivalents who also have an interest in maximizing what they bill. And so what seem like non profit-motivated groups fail either by miscalculating costs and going bust or turning out to be (or become) cost predators in what was originally sheep's clothing.

In all this I'm assuming "maximize profit" is a terrible motive. Unimaginative and cringe for one -- you could aim so much higher! -- and leading to huge externalities for everyone else.

So my current thinking is that the self- vs community-hosting vs self-sovereign debate misses the point. No matter how you arrange bits and atoms, you will depend on services provided by others. The question is how to make these arrangements sustainable for the earth and sustainable for human relations.

There are maker spaces which already manage sharing community resources via a monthly donation fee. Seems less useful for stuff like git hosting but I can imagine no-one would be against it.

There is a somewhat canonical guide to setting such an organization here (for the UK), which would be a bit different with no tools or physical space involved but some of the legal structures remain. I imagine US has one too.

yes, I think a Maker space is a good model - a digital maker space

In line with Kartik Agaram's comment, I think what we need most right now is people experimenting with the management and governance of digital services.

Codeberg is one such experiment: a forge run by an association. If you want to participate in governance, you sign up as a member. social.coop is another such experiment: a Mastodon instance managed and governed by its users. I am sure there are more examples.

Both Codeberg and social.coop share the problem that governance participation is too much of a burden for small-scale users. For both forges and social networks, I'd prefer to pay someone I trust, while having the option to move elsewhere if that trust is broken.

cosocial.ca is another example, I agree that both of those models are inspiring, and that moderation is the big reason to prefer a large central server to more smaller ones

One idea is to store vector embeddings in extended attributes: vectorvfs.readthedocs.io/en/latest

tagspaces.com is another which can store attributes either in filename itself or in sidecar json files.

I think the hard parts here are UX related:

• more (quality) labels are better for search, but more labels mean a) harder to maintain, b) more time to add (even if you make forking / templates a thing) c) managing labels becomes it's own problem
• labels themselves have privacy/security issues. Who is allowed to search for what and on what basis? "all documents Jaime sent to their lawyer in the past week". This in itself has huge perf implications.
• Who is allowed to add labels? Are events like file open/save labels? Do we scan files to auto-add labels (the attack vectors here are amazing)?
• Do we embed dependency (ex: all files needed to run a game, all the photos/videos/music in some album or doc)? Is changing a dependency auto-COW, ignored (broken?), or put choice onto the changer (who may be ignorant to the impact)

This is a lot for end users, on top of assuming SQL/Venn like searches are actually wanted by users (A and B but not C). Also unlike web search, the feedback size is small, so harder/impossible to train a model on. The best you could hope for is to tweak some parameters/weights between pre-trained models.