4 ms·

Issues and other GH infrastructure is arguably a bigger problem. That metadata is locked within the Github silo with no easy way to export it elsewhere.

dom96 9y ago
This is indeed the crux of the problem. I've been thinking about this a lot (and I wouldn't be surprised if it exists already), we need a decentralised method of storing issues and other things inside our git repos.
- leejo 9y ago
  I know of at least one solution: https://bifax.org/ https://bifax.org/
  - Procrastes 9y ago
    Great link, thanks! I've been looking for something like this.
- notheguyouthink 9y ago
  Also, the workflow on Github is one many people like, and it differs a bit if you have to use git "the old fashioned way". Not that it's hard or impossible, but it differs. I can't imagine explaining the GitHub-less workflow to my colleges..
  - notheguyouthink 9y ago
    \*colleague.
- jcelerier 9y ago
  it's an issue for issues, but wikis at least are also git repos : https://help.github.com/articles/adding-and-editing-wiki-pages-locally/ https://help.github.com/articles/adding-and-editing-wiki-pag...
- zeveb 9y ago
  If you think about it, there's no particular reasons why the metadata can't live in (and be tracked by) the repo itself. Issues could live in /issues. Simple command-line (or GUI) tools could edit them. I'm thinking in particular of how password-store[0] makes tracking history in a git repo invisible: it Just Works™. Discussions could live in /discussions, stored in something like RFC822 format. Again, simple CLI (or GUI, if you swing that way) tools could manipulate this easily. A wiki can, again, live in the same repo. PRs are a little different, since they really do need to live outside the repo. But what is a PR other than someone saying, 'hey, please pull my branch into yours'? [0] https://www.passwordstore.org/ https://www.passwordstore.org/
  - Klathmon 9y ago
    PRs and other things could also just live in a "shadow repo". Even if just by convention. You have a `Product` repo and a `Product-meta` repo. The biggest issue I have with using git as a truly decentralized system is remote management. Unless you want to be manually futzing with remotes on every single client and pushing/fetching from others correctly, you need some kind of central server. I really think there is a hole here for a product that works with git underneath, but gives a nice easy way to manage all that complexity.
    - hossbeast 9y ago
      Like GitHub?
      - Klathmon 9y ago
        I missed a word there, I meant a "decentralized way of managing all that complexity"!
- musicmatze 9y ago
  https://github.com/neithernut/git-dit https://github.com/neithernut/git-dit provides a distributed issue tracker inside git, without cluttering the repository with unneeded files and also gives the possibility for having tree-like conversation, referencing issues and so on. Unfortunately, no non-cli frontend exists right now (feel free to build one, shouldn't be complicated). Also some convenience is still missing, but could easily be integrated. What's also missing is a way to give users of the tool access to a repository where they can submit issues (which then could also be used by a web/gui frontend for the tool). This is not the domain of git-dit itself, but a solution needs to be found. One idea would be a publish repo (where everyone can push) which automatically does some sanity-verification on the issues and forwards them to the maintainers repository... or something like that. Also, https://github.com/vitiral/artifact/ https://github.com/vitiral/artifact/ is a really nice tool to do planning of an application or library inside a git repository. I am currently starting using it in iamg (https://imag-pim.org https://imag-pim.org) and it is really wonderful. The author currently does a reimplementation of its core functionality to make it even more powerful.
- WorldMaker 9y ago
  There are several attempts at tracking issues inside a repository. What we really need to sell the concept, though, I think is one that can reasonably sync with GitHub Issues. GitHub Issues are a reasonable front end for issue reporting for casual and non-technical users and if you can interoperate with them you don't have to reinvent that basic CMS. Every now and then I sketch ideas on the subject, but haven't yet gotten someone to pay me to build it. ;)

dom96 9y ago

This is indeed the crux of the problem. I've been thinking about this a lot (and I wouldn't be surprised if it exists already), we need a decentralised method of storing issues and other things inside our git repos.

leejo 9y ago
I know of at least one solution: https://bifax.org/ https://bifax.org/
- Procrastes 9y ago
  Great link, thanks! I've been looking for something like this.
notheguyouthink 9y ago
Also, the workflow on Github is one many people like, and it differs a bit if you have to use git "the old fashioned way". Not that it's hard or impossible, but it differs. I can't imagine explaining the GitHub-less workflow to my colleges..
- notheguyouthink 9y ago
  \*colleague.
jcelerier 9y ago
it's an issue for issues, but wikis at least are also git repos : https://help.github.com/articles/adding-and-editing-wiki-pages-locally/ https://help.github.com/articles/adding-and-editing-wiki-pag...
zeveb 9y ago
If you think about it, there's no particular reasons why the metadata can't live in (and be tracked by) the repo itself. Issues could live in /issues. Simple command-line (or GUI) tools could edit them. I'm thinking in particular of how password-store[0] makes tracking history in a git repo invisible: it Just Works™. Discussions could live in /discussions, stored in something like RFC822 format. Again, simple CLI (or GUI, if you swing that way) tools could manipulate this easily. A wiki can, again, live in the same repo. PRs are a little different, since they really do need to live outside the repo. But what is a PR other than someone saying, 'hey, please pull my branch into yours'? [0] https://www.passwordstore.org/ https://www.passwordstore.org/
- Klathmon 9y ago
  PRs and other things could also just live in a "shadow repo". Even if just by convention. You have a `Product` repo and a `Product-meta` repo. The biggest issue I have with using git as a truly decentralized system is remote management. Unless you want to be manually futzing with remotes on every single client and pushing/fetching from others correctly, you need some kind of central server. I really think there is a hole here for a product that works with git underneath, but gives a nice easy way to manage all that complexity.
  - hossbeast 9y ago
    Like GitHub?
    - Klathmon 9y ago
      I missed a word there, I meant a "decentralized way of managing all that complexity"!
musicmatze 9y ago
https://github.com/neithernut/git-dit https://github.com/neithernut/git-dit provides a distributed issue tracker inside git, without cluttering the repository with unneeded files and also gives the possibility for having tree-like conversation, referencing issues and so on. Unfortunately, no non-cli frontend exists right now (feel free to build one, shouldn't be complicated). Also some convenience is still missing, but could easily be integrated. What's also missing is a way to give users of the tool access to a repository where they can submit issues (which then could also be used by a web/gui frontend for the tool). This is not the domain of git-dit itself, but a solution needs to be found. One idea would be a publish repo (where everyone can push) which automatically does some sanity-verification on the issues and forwards them to the maintainers repository... or something like that. Also, https://github.com/vitiral/artifact/ https://github.com/vitiral/artifact/ is a really nice tool to do planning of an application or library inside a git repository. I am currently starting using it in iamg (https://imag-pim.org https://imag-pim.org) and it is really wonderful. The author currently does a reimplementation of its core functionality to make it even more powerful.
WorldMaker 9y ago
There are several attempts at tracking issues inside a repository. What we really need to sell the concept, though, I think is one that can reasonably sync with GitHub Issues. GitHub Issues are a reasonable front end for issue reporting for casual and non-technical users and if you can interoperate with them you don't have to reinvent that basic CMS. Every now and then I sketch ideas on the subject, but haven't yet gotten someone to pay me to build it. ;)