Last week, I wanted to track issues (bugs, tasks, enhancements) for a private project and I could not find an issue tracker that was lightweight (command line) and dead easy to install and use. Trac is very nice and easy to use, but installing and configuring a trac instance is far from a walk in the park.
I considered using ticgit, which is a true distributed issue tracking system, i.e., tickets are hosted on a git repository and multiple contributors can manage the issues. Unfortunately, to avoid ticket number clash (e.g., you don't want Bob and Alice to create ticket #3 at the same time on their own repository), the ticket numbers are hash values like d7f2d8f6d6ec3da1a1800a33fb090d590a533bac or d7f2d8. That's just unacceptable to me because my brain is not wired to think about ticket d7f2d8. I don't see myself typing that kind of identifiers on the command line too. Finally, I'm not even sure it would work for teams because talking about ticket d7f2d8 adds a lot more cognitive overload than talking about ticket #7.
Long story short, I created my own small issue tracking system for personal projects: gitli. You can pronounce it the way you want, but I prefer to say "jit lee" (jet li anyone?). You can install it the way you install any python package (e.g.,
pip install gitli) or you can just download the files and put them on your
Using gitli is easy:
git init git li init git li new 'This is my first ticket' git li -h #get some help!
gitli is not a distributed issue tracker so conflicts can occur if multiple developers create issues on their own repository. Because the datastore is a set of line-based text files, I hope that merging such conflicts will be easy. In any cases, gitli was not intended to supplement centralized (or distributed) issue tracking systems. It's just a nice hack for personal projects.