4 ms·

> To the "Git is distributed!" crowd: the issue isn't Git, it's the infrastructure we rely on around it: issues, PRs, Actions, etc. A suggestion: use git-bug h

> To the "Git is distributed!" crowd: the issue isn't Git, it's the infrastructure we rely on around it: issues, PRs, Actions, etc. A suggestion: use git-bug https://github.com/git-bug/git-bug https://github.com/git-bug/git-bug in addition to migrating to another forge like Codeberg. It saves issues, PRs etc in git itself (not on a branch - on a specially crafted ref). It offers two way sync with a lot of providers. Other VCSes like fossil store issues alongside the repo. I think it's appropriate because in a sense, issues are part of what gives meaning to the code (like documentation)

senko 6mo ago
Maybe Mitchell will pull a Linus and, out of frustration, take a weekend off to write the distributed infrastructure for issues, PRs, actions, etc. around git.
- oever 6mo ago
  It was 10 days, but that's fine too.
- Zambyte 6mo ago
  https://radicle.dev/ https://radicle.dev/
  - nextaccountic 6mo ago
    Are radicle issues and PRs stored in the Git repository itself, or is it out of band like other forges, with just federation on top?
    - gsaslis 6mo ago
      yes, they're stored in git itself. See https://radicle.dev/guides/protocol#collaborative-objects https://radicle.dev/guides/protocol#collaborative-objects
- jancsika 6mo ago
  The most important part of Linus' project was day -1, when he sliced off all the chunks of work that depend on solving open research problems. You don't want to start your Saturday morning declaring an _action struct, then filling the rest of the day staring at research papers about the current state of fast homomorphic encryption.
- jolaflow 6mo ago
  Check out Epiq https://github.com/ljtn/epiq https://github.com/ljtn/epiq It was born out of frustration and does just that. It is about to go v1 within days.
lucb1e 6mo ago
I didn't know of this, that special ref mechanism sounds really cool! Thanks for the protip
- alienbaby 6mo ago
  We've had trouble with git and repo's that have used non standard refs. It's all fine and fancy until we wanted to use some tooling that works with git, except it wouldn't see our unusual refs, and because they were non standard they were effectively hidden unless you knew they were there. So the migration work (almost) silently lost 10+ years of old work that was hiding away under those non standard refs.
stryan 6mo ago
git-bug is great but it doesn't handle PRs nor does it have a method for users without commit rights to submit bugs to the project. I know they're working on the latter (something with the web UI?) but until then you still need some kind of public infra for issue management if you want the general public to be able to submit issues. I use it for my project[0] to keep issues centralized with the repo, but I still use Github Discussions as a pseudo-bug tracker to let random users provide input. If it's a bug I add it to git-bug and sync it to Github issues for public viewing[1], but if you want use bug reports that's not really going to work. [0] https://github.com/stryan/materia https://github.com/stryan/materia [1] Ironically I got this workflow idea from ghostty and mise, both of which require users to submit bug reports as discussions first and only generate tagged issues once an actionable bug is determined.
- nextaccountic 6mo ago
  For me the main issue with git-bug is that they are not dogfooding it. However, it's also one of the few projects that is actually trying to solve the core problem, rather than skirting around it. (well I now learned of radicle in this thread and they seem to store issues in git and even have PR support I think)
  - sudoforge 6mo ago
    > For me the main issue with git-bug is that they are not dogfooding it. This is incorrect. $ git remote get-url origin ssh://git@github.com/git-bug/git-bug.git $ for n in bugs identities; do echo "${n} on the remote: " $(git ls-remote origin "refs/${n}/\*" | wc -l); done bugs on the remote: 453 identities on the remote: 311 See the related issue for more info: https://github.com/git-bug/git-bug/issues/1221#issuecomment-2884336629 https://github.com/git-bug/git-bug/issues/1221#issuecomment-... That said, yes, GitHub is still our source of truth, as our web application does not currently support "guest" access, and there are other platform features that our community uses that we do not currently have support for (e.g. discussions and pull requests). Big changes to the web ui are coming soon, which will help to unlock the ability to do these things. I've also been in talks with the Radicle team about possible collaboration.
Twirrim 6mo ago
> Other VCSes like fossil store issues alongside the repo. I think it's appropriate because in a sense, issues are part of what gives meaning to the code (like documentation) I was thinking about fossil in the context of agentic workflows the other day, after seeing a co-worker go all in on sort of shifting themselves to a TPM workflow, using a locally hosted kanban board (inspired by OpenAI's Symphony). It'd make things easier to have everything shoved into the repo, other than that everything is now shoved in the same repo being handled by the barely constrained chaos monkey that is an LLM coding agent. Locking things down gets hard if it's got access to the whole thing there.
chungy 6mo ago
> Other VCSes like fossil store issues alongside the repo. Technically the issues in Fossil are part of the repository, along with the wiki, code, forum, etc. They come along with every clone and (mostly) cannot be deleted from the historical record. Items of Fossil that are merely "alongside" instead of actually in the repository include unversioned files, chatroom content, and users and access controls. (Not an exhaustive list.)
0xbadcafebee 6mo ago
Even if you only used raw git with GitHub, it still wouldn't work. Pushing changes from my laptop would fail for hours when their SSO would break.
casey2 6mo ago
It's definitely time to turn these loose web features into a real program. I don't understand the desire to clone github as a website. It's demonstrably 10,000x more work to maintain github.com than a "github" command.
samuell 6mo ago
There is also epiq, which is a bit more bleeding edge but has a more powerful UI story, being a TUI app, providing an issue board in the terminal: https://github.com/ljtn/epiq https://github.com/ljtn/epiq
- nextaccountic 6mo ago
  Oh that's interesting! Does it have bidirectional tracking with Github? (if I create or comment on an issue in Github it will be reflected on epiq, and if I create on epiq, some bot will post it to Github). For me this is the key feature. Also > The system is designed to assure robustness and uses a number of techniques and design patterns to avoid merge conflicts. I think the docs should describe this in detail. Anyway maybe ask him to post this to HN some day!
  - jolaflow 6mo ago
    Hey! Creator of Epiq here. Epiq is platform agnostic mening that it is doing its own thing and does not connect to github issues. Epiq maintains its own board definition as an immutable (append only) event log, which is synchronized using git. An integration layer with github issues or other platforms is definitely not unthinkable. V1 is about to be released in the coming days.
  - jolaflow 6mo ago
    > I think the docs should describe this in detail. Thanks for the feedback. I will add a section about that in the readme! [EDIT] - readme updated with section about event sourcing strategy

senko 6mo ago

Maybe Mitchell will pull a Linus and, out of frustration, take a weekend off to write the distributed infrastructure for issues, PRs, actions, etc. around git.

oever 6mo ago
It was 10 days, but that's fine too.
Zambyte 6mo ago
https://radicle.dev/ https://radicle.dev/
- nextaccountic 6mo ago
  Are radicle issues and PRs stored in the Git repository itself, or is it out of band like other forges, with just federation on top?
  - gsaslis 6mo ago
    yes, they're stored in git itself. See https://radicle.dev/guides/protocol#collaborative-objects https://radicle.dev/guides/protocol#collaborative-objects
jancsika 6mo ago
The most important part of Linus' project was day -1, when he sliced off all the chunks of work that depend on solving open research problems. You don't want to start your Saturday morning declaring an _action struct, then filling the rest of the day staring at research papers about the current state of fast homomorphic encryption.
jolaflow 6mo ago
Check out Epiq https://github.com/ljtn/epiq https://github.com/ljtn/epiq It was born out of frustration and does just that. It is about to go v1 within days.

lucb1e 6mo ago

I didn't know of this, that special ref mechanism sounds really cool! Thanks for the protip

alienbaby 6mo ago
We've had trouble with git and repo's that have used non standard refs. It's all fine and fancy until we wanted to use some tooling that works with git, except it wouldn't see our unusual refs, and because they were non standard they were effectively hidden unless you knew they were there. So the migration work (almost) silently lost 10+ years of old work that was hiding away under those non standard refs.

stryan 6mo ago

git-bug is great but it doesn't handle PRs nor does it have a method for users without commit rights to submit bugs to the project. I know they're working on the latter (something with the web UI?) but until then you still need some kind of public infra for issue management if you want the general public to be able to submit issues. I use it for my project[0] to keep issues centralized with the repo, but I still use Github Discussions as a pseudo-bug tracker to let random users provide input. If it's a bug I add it to git-bug and sync it to Github issues for public viewing[1], but if you want use bug reports that's not really going to work. [0] https://github.com/stryan/materia https://github.com/stryan/materia [1] Ironically I got this workflow idea from ghostty and mise, both of which require users to submit bug reports as discussions first and only generate tagged issues once an actionable bug is determined.

nextaccountic 6mo ago
For me the main issue with git-bug is that they are not dogfooding it. However, it's also one of the few projects that is actually trying to solve the core problem, rather than skirting around it. (well I now learned of radicle in this thread and they seem to store issues in git and even have PR support I think)
- sudoforge 6mo ago
  > For me the main issue with git-bug is that they are not dogfooding it. This is incorrect. $ git remote get-url origin ssh://git@github.com/git-bug/git-bug.git $ for n in bugs identities; do echo "${n} on the remote: " $(git ls-remote origin "refs/${n}/\*" | wc -l); done bugs on the remote: 453 identities on the remote: 311 See the related issue for more info: https://github.com/git-bug/git-bug/issues/1221#issuecomment-2884336629 https://github.com/git-bug/git-bug/issues/1221#issuecomment-... That said, yes, GitHub is still our source of truth, as our web application does not currently support "guest" access, and there are other platform features that our community uses that we do not currently have support for (e.g. discussions and pull requests). Big changes to the web ui are coming soon, which will help to unlock the ability to do these things. I've also been in talks with the Radicle team about possible collaboration.

Twirrim 6mo ago

> Other VCSes like fossil store issues alongside the repo. I think it's appropriate because in a sense, issues are part of what gives meaning to the code (like documentation) I was thinking about fossil in the context of agentic workflows the other day, after seeing a co-worker go all in on sort of shifting themselves to a TPM workflow, using a locally hosted kanban board (inspired by OpenAI's Symphony). It'd make things easier to have everything shoved into the repo, other than that everything is now shoved in the same repo being handled by the barely constrained chaos monkey that is an LLM coding agent. Locking things down gets hard if it's got access to the whole thing there.

chungy 6mo ago

> Other VCSes like fossil store issues alongside the repo. Technically the issues in Fossil are part of the repository, along with the wiki, code, forum, etc. They come along with every clone and (mostly) cannot be deleted from the historical record. Items of Fossil that are merely "alongside" instead of actually in the repository include unversioned files, chatroom content, and users and access controls. (Not an exhaustive list.)

0xbadcafebee 6mo ago

Even if you only used raw git with GitHub, it still wouldn't work. Pushing changes from my laptop would fail for hours when their SSO would break.

casey2 6mo ago

It's definitely time to turn these loose web features into a real program. I don't understand the desire to clone github as a website. It's demonstrably 10,000x more work to maintain github.com than a "github" command.

samuell 6mo ago

There is also epiq, which is a bit more bleeding edge but has a more powerful UI story, being a TUI app, providing an issue board in the terminal: https://github.com/ljtn/epiq https://github.com/ljtn/epiq

nextaccountic 6mo ago
Oh that's interesting! Does it have bidirectional tracking with Github? (if I create or comment on an issue in Github it will be reflected on epiq, and if I create on epiq, some bot will post it to Github). For me this is the key feature. Also > The system is designed to assure robustness and uses a number of techniques and design patterns to avoid merge conflicts. I think the docs should describe this in detail. Anyway maybe ask him to post this to HN some day!
- jolaflow 6mo ago
  Hey! Creator of Epiq here. Epiq is platform agnostic mening that it is doing its own thing and does not connect to github issues. Epiq maintains its own board definition as an immutable (append only) event log, which is synchronized using git. An integration layer with github issues or other platforms is definitely not unthinkable. V1 is about to be released in the coming days.
- jolaflow 6mo ago
  > I think the docs should describe this in detail. Thanks for the feedback. I will add a section about that in the readme! [EDIT] - readme updated with section about event sourcing strategy