Hacker News Reader

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

Yeah, thats not a bad approach. Do you plan to add a (Web)GUI to it?

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.

The man page has a little more info: https://github.com/neithernut/git-dit/blob/master/git-dit.1....

It's unfortunate that github doesn't support rendering manpages the way it supports rendering READMEs written in markdown and various other languages.

Pandoc support writing Man format, but not reading it, http://hackage.haskell.org/package/pandoc

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?

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

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

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

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…

Does my thinking make sense?

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

This is awesome and I'd like to support the effort to turn it into something robust enough for production. What's the best way to do that?

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 is a distributed issue tracker for git only

Sorry but you lost my interest completely.

The cool kids can claim that git is the best thing since sliced bread all they want, you will have to claw Mercurial from my cold dead hands.

There's b for Mercurial:

http://www.digitalgemstones.com/projects/b/

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.

Honestly BugsEverywhere is a better approach IMO.

Tying an issue tracker to a single specific VCS is unnecessary.

Veracity[0] also had the same "distributed bug tracking" feature built in. Too bad the Sourcegear guys gave up on developing it further.

[0]: http://veracity-scm.com/

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.

I never said I don't use git.

My issue is with the "only" part - as I said elsewhere, BugsEverywhere has a better approach, that works for any DVCS

I do use git, but I don't want to use an issue tracker that is tied to git, because I use mercurial too.

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.

Saying "I wish it supported other vcs'" is like saying "I wish whales could fly".

An impossible situation.

The entire way it's designed to work is inherently tied to git, and thus flawed IMO.