
Show HN: Git-dit – a distributed issue tracker for git - musicmatze
https://github.com/neithernut/git-dit
======
musicmatze
Co-Author here.

git-dit is a distributed issue tracker in/for git, currently implemented as
proof-of-concept in Bash. If you want to play with it, make sure you use
current git versions.

It differs from things like bugseverywhere and fossil in that it is a
distributed issue tracker for git only, using git features to implement issue
tracking in a way so that merging of issues, attaching issues to commits,
creating PRs, etc is possible. It does explicitely _not_ store any "structured
data" like JSON, YAML or such, but simply uses git commit messages for issue
messages. So, E-Mail workflows, github, gitlab and other hosting platforms and
their issue tracking schema can be adapted and mirrored into "git-dit",
technically. We are not there yet, though. We are planning to reimplement the
current featureset in a more robust language.

When playing with this, please keep in mind that this is a POC - there are
bugs, missing things and rough edges. Do not use on a production repository!

I'd happily answer your questions!

~~~
hammerandtongs
This is conceptually interesting but I think you would have been far better
served by spending some time on the README before posting.

Filling out the paragraph you just wrote would be a start.

Adding some proposed workflows and the steps a user would take to get there
etc.

~~~
OJFord
My main question after reading everything but the source code is "how's it
stored?" \- I would assume it just uses a .dit or similar directory, and so is
updated on pull, or does it do something more fancy inside .git?

~~~
joshka
Reading the source, the key to understanding this is at [1].

Each issue is stored as a new commit tree, and head ref stored at
.git/refs/dit/${issue_hash}/head. Issue replies are stored as commits
referencing the commit they are replying to and a ref in
.git/refs/dit/${issue_hash}/leaves/${reply_hash}

Seems pretty neat to me.

[1]: [https://github.com/neithernut/git-dit/blob/master/git-dit-
cr...](https://github.com/neithernut/git-dit/blob/master/git-dit-create-
message#L103)

~~~
detaro
Thanks for digging it out, that part really should be explained in the readme.

------
fsiefken
I like the keep it simple approach, what would be the added value compared to
keeping org-mode issue tracking files with commit and issue tags in git like
having an issues.org file where time estimates, schedules, person assigned and
'date done' can be documented with tags and properties?

* TODO [#A] :f3abe64:31415: FIX bottom row space

* TODO [#B] :d4aae31:31410: BUG add miligram property

* PENDING [#A] :f4efe20:31410: FEAT implement counter

* DONE [#B] :e4bae20:31410: FEAT implement back button

with some archival function to an issues_done.org file

~~~
gkya
Well that's what I do with my little projects and it's nice that it's not tied
to a VCS, but it doesn't scale (nor would this I guess). You'd have lots and
lots of unnecessary commits about issues and comments in your git repo and
would need to merge them etc. It's easier to set up some bug tracking system.

~~~
sitkack
Would it be a pain to put it in a branch?

My git-kung is not so good, but `git worktree add ../issues` might do the
trick.

------
erikb
Honestly I still didn't really get what makes this special. You probably
already know all the other attempts to put issue tracking into git repos. And
you probably also know that none of them succeeded in scale, and that there
are good reasons for that. I can't really see what you're doing differently
here, yet. Hope when you're further in development and have a more indepth
documentation you'll share it again.

