Hacker News Reader

Comment by hammerandtongs | Hacker News Reader

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.

View on HN

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.

Reply on news.ycombinator.com