Show HN: Bug – “distributed” issue tracking tool using plaintext files and git | Hacker News Reader

Show HN: Bug – “distributed” issue tracking tool using plaintext files and git

github.com

2 pointsdriusan5 comments

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".)

Is there something this does that bugseverywhere doesn't?

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.)

Yeah, it's a shame about the BE site. They've moved to 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? :-)

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.

Reply on news.ycombinator.com