
Show HN: Bug – “distributed” issue tracking tool using plaintext files and git - driusan
https://github.com/driusan/bug
======
driusan
This is something I threw together that I've been finding pretty useful in the
last couple days, and I figure other people might be interested in trying out.
It's a tool to treat an "issues/" directory on the filesystem as an issue
tracker, which can be tracked via git (or any other source control) and
viewed/edited from the command line with the "bug" tool.

I've been using it as a lightweight "What do I have left to do on this
branch?" tool that fits into my workflow without having to go to an external
service (ie. Redmine) or leave the terminal. The fact that it's context
sensitive (it just looks for the nearest issues/ directory) means I can just
do a "bug list" to get an instant list of outstanding tasks in whatever I
happen to be working on whenever I switch branches or get interupted and need
to remember where I was.

(I wanted to call it "context-sensitive," which is more accurate, in the
title, but HN said the title was too long, so it became "distributed," since
anything in git is "distributed".)

------
stephenr
Is there something this does that bugseverywhere doesn't?

~~~
driusan
The bugseverywhere web page currently tells you to clone from a broken
gitorious URL.. so.. installs?

The main difference is the design. BE keeps a hidden directory where
everything is referenced by hash, which means you need to take the time to set
up BE and have the client installed to use it. This is based on human readable
file and directory names and isn't concerned with title collisions, which
means that if you're stuck you can manage your issues with ls and cat (and
mkdir, I guess.)

BE is probably more powerful and mature, but this is lighter weight, has no
dependencies, and I find easier to use (possibly because I wrote it.)

~~~
stephenr
Yeah, it's a shame about the BE site. They've moved to
[https://gitlab.com/bugseverywhere/bugseverywhere](https://gitlab.com/bugseverywhere/bugseverywhere)
for reference.

I do like your approach actually, particularly as it could be easily expanded
a little, e.g. to use markdown (or similar) content and present a web view
(aka Gollum for Bugs).

Any chance you could be convinced to add support for Mercurial? :-)

~~~
driusan
Thanks for pointing that out! I thought the project was dead. I was really
interested in it when it came out and disappointed that it didn't seem to go
anywhere, but I think part of the problem is that it was too complicated to
use and it was either all in or nothing (either the whole team uses BE, or no
one is going to..)

So my approach is sort of an attempt to simplify things by going back to how
an organized person might have tracked their issues in 1970 before project
management software or source control, and then adding a couple hooks for SCM.
"bug" is just a tool to streamline it without a lot of pushd/cd/popd.

Which means that you can use all of the commands except purge and commit in
Mercurial, and then manually commit the issues directory (I think "hg commit
$(bug pwd)" should work for commit, but "hg purge" seems to require an
extension and not be built into the base install.) I'm not opposed to
supporting hg (or anything else) as a first class SCM, except that I don't use
it and wouldn't know if things were working as expected.

