5 ms·

There are a lot of different distributed issue trackers built on top of git. None widely known or used and all incompatable. If GitHub included issues and pull

by joeyh 11y ago

There are a lot of different distributed issue trackers built on top of git. None widely known or used and all incompatable. If GitHub included issues and pull requests in a git repo (either in branch or in a separate git repo as they do for wikis), it would become an instant de-facto standard. With such a standard, many new things would immediately spring up to use it. Bug reporting, and managing bug reports, and forwarding bug reports between related projects is a big pain point, largely due to the fractured mess of bug tracking systems. A thousand flowers would bloom. The only reason GitHub has to not do this, as far as I can tell, is that keeping the issues locked in their silo makes it a little bit harder for competition to migrate repositories from GitHub. Although I hear GitLab migrates issues anyway, and the API makes this not hard (although perhaps needing lots of time due to rate limiting). And of course, they probably slapped a SQL database down on day 1 for issues without thinking too much about it, and so it would be some effort to move them into the git repo now. Not holding my breath, which is why I wrote github-backup. Well, also because it recursively backs up forks, and I've lost changes in deleted forks enough times to want to back them up automatically.

jstepka 11y ago
What you're after is something like Fossil; * http://www.fossil-scm.org/ http://www.fossil-scm.org/ ... which is a distributed version control system that embeds issue and wiki data. What would be a great next step for version control (similar to how we went from cvs to svn to git) would be to embed issue and PR data into the repository data structure. I haven't worked on Git / Bitbucket in a while (at Docker now), so I haven't been tracking it very close... what would be ideal, maybe it's already there... would be to design and build on the popularity of Git with a module that stores the issue / PR data giving you true portability. Over time that module could be made mandatory giving you the flexibility you're after.
- snuxoll 11y ago
  Never heard of fossil until now, looks like an interesting project. I can see the reasoning for the lack of a rebase command but man things like git merge --squash make our commit history so much cleaner (but again, the argument raised is that the developers care about history as it happened, not as they wanted it to happen).
sytse 11y ago
At GitLab we indeed have an importer for GitHub issues (so you can import repos, pull requests and wikis in one go). But issues in a git repo would be awesome. My thoughts on this are in https://gitlab.com/gitlab-org/gitlab-ce/issues/4084 https://gitlab.com/gitlab-org/gitlab-ce/issues/4084
SOLAR_FIELDS 11y ago
Your third point is absolutely the reason that they don't have this. This is a tool on Github that helps people migrate away from Github.
toomuchtodo 11y ago
Would you mind if I integrated this into Archive Team's ArchiveBot? It currently uses youtube-dl to grab audio and video content, and your tool would be very helpful for snapshotting Github.
- joeyh 11y ago
  Of course you're welcome to do that. https://joeyh.name/blog/entry/I_am_archiveteam/ https://joeyh.name/blog/entry/I_am_archiveteam/ ;)
  - toomuchtodo 11y ago
    OH MY! :)
codemac 11y ago
Do you have any suggestions for what you think distributed issue trackers should look like? My favorite was simple defects with the prophet database backend, but it was very "outside" of git and this gave people heartache. Are there any that you have liked? Ikiwiki changed what I thought version control could be, but I never really used it for a project because I struggled with spam. I'd love to hear your thoughts on the more targeted issue tracker approaches.
- WorldMaker 11y ago
  I've experimented with a number of them over the years. I even put some effort into my own. Of the off-the-shelf ones, I like the YAML-based ones the best for the artifacts they store in the repository. ditz [1] is the grand-daddy in that space. However, given that the majority of an issue is formatted text, I think the best ones are actually based on a markup language of some sort with an easy to parse frontmatter. The one I built way back when was based on ReStructuredText and used it's nice, easy to RegEx, definition list format as frontmatter. These days I'd probably take the semi-standard "Jekyll" frontmatter approach of YAML+Markdown, and I'm somewhat surprised there still hasn't been a big tool yet (that I've seen) take that approach. (That said, you can admirably fake it with a custom Jekyll collection as-is, so maybe it's something we could build as an interesting template and/or plugin...) [1] http://ditz.rubyforge.org/ http://ditz.rubyforge.org/

by joeyh 11y ago

jstepka 11y ago

What you're after is something like Fossil; * http://www.fossil-scm.org/ http://www.fossil-scm.org/ ... which is a distributed version control system that embeds issue and wiki data. What would be a great next step for version control (similar to how we went from cvs to svn to git) would be to embed issue and PR data into the repository data structure. I haven't worked on Git / Bitbucket in a while (at Docker now), so I haven't been tracking it very close... what would be ideal, maybe it's already there... would be to design and build on the popularity of Git with a module that stores the issue / PR data giving you true portability. Over time that module could be made mandatory giving you the flexibility you're after.

snuxoll 11y ago
Never heard of fossil until now, looks like an interesting project. I can see the reasoning for the lack of a rebase command but man things like git merge --squash make our commit history so much cleaner (but again, the argument raised is that the developers care about history as it happened, not as they wanted it to happen).

sytse 11y ago

At GitLab we indeed have an importer for GitHub issues (so you can import repos, pull requests and wikis in one go). But issues in a git repo would be awesome. My thoughts on this are in https://gitlab.com/gitlab-org/gitlab-ce/issues/4084 https://gitlab.com/gitlab-org/gitlab-ce/issues/4084

SOLAR_FIELDS 11y ago

Your third point is absolutely the reason that they don't have this. This is a tool on Github that helps people migrate away from Github.

toomuchtodo 11y ago

Would you mind if I integrated this into Archive Team's ArchiveBot? It currently uses youtube-dl to grab audio and video content, and your tool would be very helpful for snapshotting Github.

joeyh 11y ago
Of course you're welcome to do that. https://joeyh.name/blog/entry/I_am_archiveteam/ https://joeyh.name/blog/entry/I_am_archiveteam/ ;)
- toomuchtodo 11y ago
  OH MY! :)

codemac 11y ago

Do you have any suggestions for what you think distributed issue trackers should look like? My favorite was simple defects with the prophet database backend, but it was very "outside" of git and this gave people heartache. Are there any that you have liked? Ikiwiki changed what I thought version control could be, but I never really used it for a project because I struggled with spam. I'd love to hear your thoughts on the more targeted issue tracker approaches.

WorldMaker 11y ago
I've experimented with a number of them over the years. I even put some effort into my own. Of the off-the-shelf ones, I like the YAML-based ones the best for the artifacts they store in the repository. ditz [1] is the grand-daddy in that space. However, given that the majority of an issue is formatted text, I think the best ones are actually based on a markup language of some sort with an easy to parse frontmatter. The one I built way back when was based on ReStructuredText and used it's nice, easy to RegEx, definition list format as frontmatter. These days I'd probably take the semi-standard "Jekyll" frontmatter approach of YAML+Markdown, and I'm somewhat surprised there still hasn't been a big tool yet (that I've seen) take that approach. (That said, you can admirably fake it with a custom Jekyll collection as-is, so maybe it's something we could build as an interesting template and/or plugin...) [1] http://ditz.rubyforge.org/ http://ditz.rubyforge.org/