pksunkara

Jujutsu is mentioned as one of the features we support down the page. And since we plan to support both git and jujutsu, there's no specific mention on VCS

I don't see benchmarks anywhere in here. For example, how many pushes per second does this handle? And how many concurrent pushers? etc..

Disclaimer: I am building a code forge at https://juju.bi

Yes, we will be offering official CI (though nowhere near as free as GitHub). We will also support 3rd-party CIs (like https://buildkite.com, https://depot.com) & self-hosted runners (similar to GitHub)

I think they all have different philosophies in approaching the problem.

* https://juju.bi - Local-first architecture

* https://cursor.com/docs/origin - Scalable VCS backend (this is actually very easy to implement by others)

* https://tangled.org, https://radicle.dev - Distributed forges

* https://entire.com - Very agent-centric

I think all they have to do is stop giving free CI to everyone and this reliability issue will be solved immediately.

Disclaimer: I am building a code forge myself at https://juju.bi

I see in the post that lexicon has been finalized. Does that include putting the issue, pr & comment records under the repo scope instead of the user scope?

I am asking because I have been waiting for that change. I intend to make all the public repos from https://juju.bi (code forge I am building) interoperable with Tangled and basically behave as knot server.

I am trying to approach this problem from a different perspective at https://juju.bi

Can someone tell me why people prefer temporal over something like https://restate.dev?

I am working on a code forge that can work offline for the collaborative stuff. https://juju.bi

Yes, it is a cloud service and CI. It is not region specific for now since I am not in EU.

How is this different from a custom forgejo hosted in europe? What features does this provide compared to traditional code forges?

Disclaimer: I am building https://juju.bi, therefore you don't need to answer if uncomfortable.

I am working on a GitHub compatible API for my code forge at https://juju.bi, and thus all the existing integrations of GitHub should theoretically work with my code forge too.

FWIW, I really like what Tangled is doing and I agree that we need a federation of forges. Which is why, I am planning to use ATproto too for public repositories in the code forge I am building, https://juju.bi

I am building a new code forge at https://juju.bi

It's not agent-first, but I can't think of any features that are needed for agents other than scalability.

Let me start off (assuming all code forges have PRs)

  1. Branch protection rules
  2. CI
  3. Terraform provider (API)

I would love to know the need behind pushing over HTTPS. Is the SSH protocol not good?

I think the CLI is useful for pushing. What do you use to push all the rebased child branches?

I am still curious why they stopped offering their original service. What was the feedback from users? Why did developers not want to use it?

Thanks, missed that part. I would still be interested in knowing how much additional storage that adds, if the OP is interested in updating the article.

I think a stored generated column allows you to create an index on it directly. Isn't it better approach?

I am working on something for that at https://automa.app. Let me know if you are interested in trying it out.

Actually,

1. `color` feature and thus the `anstream` dep is optional.

2. Even if you use it, it handles all the behaviour correctly regarding the piping and no color support, which is why it is a dependency in the first place.

Source: I am clap maintainer

This ulid Postgres extension doesn't have any performance issues compared to native uuidv7 in Postgres. https://github.com/pksunkara/pgx_ulid. Just wanted to bring it up since it looks like the author didn't come across it when looking for ulid generators in postgres.

Disclaimer: I built it.

Where can I learn more about this? You guys don't seem to have any docs available.