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!
> We are planning to reimplement the current featureset in a more robust language.
I saw on your projects list that you plan to port it from shell to Rust. Nice choice. I had a great experience using Rust for git-series (https://github.com/git-series/git-series/ ); the git2-rs binding is a joy to use.
If you run into any issues along the way, or want some help with git2-rs, I'd be happy to chat about it. (And, of course, feel free to borrow anything from git-series; if you find something useful and non-trivial that you'd like to share, let me know and I can extract it into a crate.)
Awesome, thanks for your feedback! Yes, we did consider C++ as well, but IMHO the tooling is better with Rust and we are both familiar with it, so that seems to be the better choice.
I built something similar some months ago. Started storing data in json but then moved to commit messages. Its a fun challenge but gave up because I felt that this pollited git. I then wondered why Linus did not incorporate something like it, but figured that he did not want to distribute org issues with the code base. This is not a criticism on your work but an observation. :)
Hi. Thanks for your reply. We already thought of that, and we concluded that it would be a great idea to make it configurable whether the current repository (the `pwd`) should be used for issue storage or another git repository. So one can have one repo for code and another for issues, giving them the possibility to transfer issues from the issue-repo to the code repo, if desired.
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?
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}
Not sure how they are doing it, but I'd actually do it with a new root commit and branches in git. That way merging is easily doable and it doesn't pollute the files inside your current checkout. Sort of like how github pages works. It'd also let you potentially have multiple issue trackers in a repo if you needed to for some reason.
Absolutely, sorry that's what I meant by a directory really - otherwise you'd create your branch to fix the bug and have lost the issue!
(Though I suppose you could just say they're tracked on master and have the tool abstract access from other branches... but that would assign special meaning to master unnecessarily, in contrast to your scheme.)
From the sound of it, seems that editing issue descriptions is not possible? (E.g. for fixing typos, adding details, renaming issue title - if supported at all.) Do I understand correctly? If yes, do you have plans for this possibly?
Hi. Due to the nature of git, this is not possible after the issue is distributed to the network, hence there is no possibility to implement such a thing.
Interesting. So from what I can see, each issue report and each comment is a ref, like a branch. There's no master file with a list of issues; listing issues/comments is done the same way as listing branches. This avoids the need for an explicit merge step when pulling or pushing; doing one of those 'just works' and combines the list of issues seen by each side. Editing a report or comment seems to not be currently supported, but could be implemented as adding a commit to the branch. So you'd get full edit history just by running 'git log', and if there were conflicting edits to the same report/comment on the local and remote side, git would try to merge just like any other branch divergence. But the dit wrapper script could configure it to bail out by default and force the user to deal with it.
The main obstacle I can see is access control. Most projects would like to allow issue contributions from anyone but limit commit access to the code (obviously). This doesn't map well to public hosting services' access models; even if you use separate repos for issues and code, (a) at least GitHub doesn't even have an "allow commits from anyone" option, and (b) even if there were such an option, you don't want to allow anonymous users to edit any comment, which corresponds to minimal traditional 'commit access', let alone force push or delete, which usually comes along with it. But you do want to allow users to edit their own comments, which might be possible with custom logic based on signed commits.
So basically one would want a custom 'pre-receive' or 'update' hook. I imagine a suitable script will eventually be included in the git-dit repo, which should work fine for self-hosting, but public Git hosting services don't allow uploading arbitrary hook scripts. (GitHub has webhooks, but they're asynchronous so can't block commits, and as I said, there's no anyone-can-commit option anyway.) I guess projects which want to be on GitHub could host an intermediate repo somewhere which allows pushes from anyone but filters them, then pushes on to GitHub from a trusted account…
Hi. As angrow has written, yes, patches/patchmails would be an option. We did this explicitly leaving out the access-control problem, which is a hard problem by itself.
Currently we would think of emails as first step, which clearly would make it harder for newbies, true. We also thought about other possible workflows but in the end a project needs some people accepting issues. This could be automated with git-dit of course - something like `git dit fetch-issues --from repo@repohost` which then asks the maintainer for each new issues to review and accept or reject it with a single keystroke. Either way, we currently see no way around that problem.
> Either way, we currently see no way around that problem.
Hrm… assuming you mean in general rather than just on GitHub/etc., why wouldn't a pre-receive hook work? Not that `git dit push` is especially friendly to newbies (for that there's no way around a web interface, which is of course a possibility), but it would provide a standard 'protocol' for submission. It's not great if the maintainer needs to approve not only every issue but every comment from the public.
Or you could just treat issues as another kind of patch, which anyone could send by email or pull request, and maintainers could accept, reject, modify, clarify, etc.
It's true this would be harder for less technical users to submit problems. You might want a way to map anything submitted by Github Issues or the like into patches, though you could also do it manually.
Hi. Awesome you want to contribute! Well, take part in discussions in the github issues (which should be transferable at some point and therefor also show up in git-dit), would be the first step. We now have to sort out what our next steps are...
It's not very active, but it's the same idea. Distributed bug tracking has been around for a long time. I think Fossil also does it and probably has the tightest integration, since it's Fossil.
I'm disappointed in HN community for how this comment was treated. I'm a git lover, but this comment is a valid, well (enough) presented opinion. We live on people having different opinions. That's what makes us stronger than other communities!
@stephenr: Well then you'll miss stuff like that. I honestly recommend checking out git in depth in your spare time. Just like learning lisp it will increase your programming skills even if you never use git in production! Maybe you come to love it for the same reason I do: incredibly well done architecture under the hood. It's the first time I could completely grasp what a VCS wants to do and how it's achieving its goals.
If this tool isn't of interest to them, why are they reading the comments and then going further to bother commenting here though? Why did it ever have their interest to lose it? The very first word in the title is 'git'. If they don't use git then why are they in this part of town?
It's like if there was a post on some other forum about kayaking and I went out of my way to say 'sorry this isn't interesting to me because I'm into cycling and don't like kayaking'. Imagine what it would be like if every HN user went down the front page and commented in every thread that mentioned a technology they don't use 'sorry I don't use this technology so this post is useless to me'.
Yes I suppose it's a totally valid opinion, but it's just entirely useless to offer it here.
The issue with the previous comment was entirely due to phrasing, in my opinion. A "Show HN" of an open source project is a gift, the socially acceptable response would be to thank and politely refuse, and maybe suggest an improvement.
"This seems interesting, but I wish it supported other VCSs - you will have to claw Mercurial from my cold dead hands!" would have made the same point, but it'd wouldn't sound like the developers somehow owed something.
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
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.
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.
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!