Background

Before COVID-19, I’ve been reviewing issues on a bus to work. My team used gitlab, so without a stable internet connection on a bus, I wasn’t able to concentrate. I started look for an offline friendly issue management tool and narrowed the contenders to (i) git-issue and (ii) git-bug.

I decided to give a shot at git-issue because I liked its simplicity. My first impression of git-issue was basically an issue manager powered by git. It provided command-line tools for basic issue management like creating, editing, removing, listing issues and comments and also had additional features like logging time estimates/spent and setting milestones. It was written in shell script.

The Pros and Cons List

After 2 weeks of using it here is my pros and cons list.

Pros:

  • lightweight
  • based on git
  • supports interacting with github/gitlab

Cons:

  • github/gitlab integration is buggy
  • written in shell script so hard to read & debug the src code

My Honest Opinion

My initial motivation was doing project management when I have don’t have access to the internet, e.g., on a bus. I couldn’t replace my existing workflow–I used to use GitLab’s issue board–because there were tons of project management features GitLab provided that I didn’t realize I was dependent on. For example, I wanted

  • customizable board view
  • markdown preview
  • issue number auto-completion the editing view

Also, I realized (i) connecting to the internet on a bus wasn’t as hard via tethering and (ii) there are no severe consequences of editing issues concurrently (as in using a cloud tool). For coding (ii) is not true since doing so will likely crash your program.

I ended up mostly using git-issue when I know when exactly what to do, e.g., comment on a specific issue. While I still think it has a lot of potentials, for now, it has not replaced my goto tool, the gitlab issues/board pages on the browser.

Misc.