9 ms·

Why Tangled instead of something more established like Codeberg, or if f/loss, Forgejo or Gitea? Just because ATProto vibes?

nerdypepper 2mo ago
disclaimer: i maintain tangled, some reasons to try might be: - tangled federates: https://blog.tangled.org/federation https://blog.tangled.org/federation - native stacked PRs: https://blog.tangled.org/stacking https://blog.tangled.org/stacking - tangled implements mitchell's vouch system: https://blog.tangled.org/vouching https://blog.tangled.org/vouching
- benrutter 2mo ago
  > - tangled federates: https://blog.tangled.org/federation https://blog.tangled.org/federation People have been talking about federation across forges for a couple of years and seems like its finally at least close to being a real thing!? That's absolutely amazing!!
  - avsm 2mo ago
    yep, I host two separate Tangled knots; one for my personal use and another for work at the Cambridge Computer Science department. Having large git repos on a server near me is great, and because I can sync the bare git repos it’s easy to run a local forge as well.
- ashu1461 2mo ago
  What are some of the practical use cases of federation in git workflows ?
arikrahman 2mo ago
Yes, separation between git storage and identity. Very simple to use your own Knot instead of the default knot1, just enter your own website link to it. Not as beholden to Github downtimes that are out of your hands. I was using Codeberg this morning, now I'm on Tangled. All I had to do was switch remote origin.
jeremyjh 2mo ago
It also has a pretty fundamental design flaw: issue /PR comments belong to the server where the commenter is hosted, not to the repo. I’m sure they will find a workaround but finding that reduced confidence they actually understand the problem they are solving.
- nerdypepper 2mo ago
  this is changing very soon :) see knot2[0] for some initial experiments: https://tangled.org/oyster.cafe/knot2 https://tangled.org/oyster.cafe/knot2 > As time goes on we are re-assessing the idea of users owning what is "collaborative data" (issues, PRs, etc.) on their PDSes - soon may come the day that an issue also lives on the knot as a source of truth, with an accompanying pointer record on user PDS to attest that it's theirs
- icy 2mo ago
  We’re solving for this very issue. Issues & pulls will belong to the repo, backed by a “COB” (collaborative object) system.
chaosharmonic 2mo ago
> something more established like Codeberg, or if f/loss, Forgejo or Gitea? Codeberg's git hosting is a Forgejo instance, actually.

nerdypepper 2mo ago

disclaimer: i maintain tangled, some reasons to try might be: - tangled federates: https://blog.tangled.org/federation https://blog.tangled.org/federation - native stacked PRs: https://blog.tangled.org/stacking https://blog.tangled.org/stacking - tangled implements mitchell's vouch system: https://blog.tangled.org/vouching https://blog.tangled.org/vouching

benrutter 2mo ago
> - tangled federates: https://blog.tangled.org/federation https://blog.tangled.org/federation People have been talking about federation across forges for a couple of years and seems like its finally at least close to being a real thing!? That's absolutely amazing!!
- avsm 2mo ago
  yep, I host two separate Tangled knots; one for my personal use and another for work at the Cambridge Computer Science department. Having large git repos on a server near me is great, and because I can sync the bare git repos it’s easy to run a local forge as well.
ashu1461 2mo ago
What are some of the practical use cases of federation in git workflows ?

arikrahman 2mo ago

Yes, separation between git storage and identity. Very simple to use your own Knot instead of the default knot1, just enter your own website link to it. Not as beholden to Github downtimes that are out of your hands. I was using Codeberg this morning, now I'm on Tangled. All I had to do was switch remote origin.

jeremyjh 2mo ago

It also has a pretty fundamental design flaw: issue /PR comments belong to the server where the commenter is hosted, not to the repo. I’m sure they will find a workaround but finding that reduced confidence they actually understand the problem they are solving.

nerdypepper 2mo ago
this is changing very soon :) see knot2[0] for some initial experiments: https://tangled.org/oyster.cafe/knot2 https://tangled.org/oyster.cafe/knot2 > As time goes on we are re-assessing the idea of users owning what is "collaborative data" (issues, PRs, etc.) on their PDSes - soon may come the day that an issue also lives on the knot as a source of truth, with an accompanying pointer record on user PDS to attest that it's theirs
icy 2mo ago
We’re solving for this very issue. Issues & pulls will belong to the repo, backed by a “COB” (collaborative object) system.

chaosharmonic 2mo ago

> something more established like Codeberg, or if f/loss, Forgejo or Gitea? Codeberg's git hosting is a Forgejo instance, actually.