Jun 23, 2017

What if Git Issue Trackers used Git?

On my drive home today I was thinking about how there’s some dissonance between DVCS’s and the issue-tracking systems that accompany them more and more these days. GitHub has one. GitLab has one. Atlassian sorta has two if you count JIRA and Bitbucket separately. And… *drum roll* they’re non-transferrable. What the heck? The repositories are! Why not the issues? Are they not important as well? There’s a lot of project history and meta-documentation to be found in issue-tracking systems.

A Git repository can live anywhere. You can clone it and push it anywhere. It seems strange that issues don’t come along for the journey. I routinely utilize multiple remotes, and where they’re hosted is arbitrary. I have some respositories that exist on Bitbucket, GitHub, and a private GitLab instance. Why? Not important. What’s important here is that each of these have incompatible issue tracking systems.

One emergent pattern I’ve seen is the formation of Wiki repositories: a collection of markdown documents that are loosely coupled to a main repository. They have their own repository history and exist as a sibling to the main repository. Why not do something similar with issue tracking? They have history. They could be coupled to one repository or used across many. Each issue is essentially a document.

There’s a project out there called gaskit that aims to do this, though it seems to still be in its infancy. There’s another one called cil that looks like it’s meant to be used for managing the issues as documents via command line. Neither quite seem to be what I’m imagining, but at least I’m not alone in being frustrated with non-transferrable issue tracking.