musicmatzeMar 16, 2018

I wrote a #web #frontend for #git #dit - the distributed issue tracker for git.

It currently can _view_ things, there's no "Add issue" or "Reply" functionality and it is _not_ intended for web-facing (but running locally for local repositories).

Read more about the development and why (also #screenshots): https://beyermatthias.de/blog/2018/03/16/writing-a-git-dit-web-frontend-with-gotham-libgitdit-and-love/

Or check out the repository at: https://github.com/matthiasbeyer/git-dit-wui

<3

Writing a git-dit web frontend with gotham, libgitdit and love

I love the Rust language. And I love the library ecosystem the Rust community provides. But let me start at the beginning. libgitdit In 2016, I and a friend of mine developed a library for distributed issue tracking with git and a commandline frontend for that library. The project, git-dit got a rather good portion of attention on hackernews, reddit and of course on github. Ranking at about 350 stars on github, this is the most successfull piece of software I (co-)authored so far.

Show threadHallå KittehMar 16, 2018
@musicmatze Checked if dit was listed at https://dist-bugs.branchable.com/software/ . It is!

An issue is a chain of commit messages? So you can read the issue convo in reverse chronological order with just git log, that's an interesting approach!
software

Show threadmusicmatzeMar 16, 2018
@clacke Yep. But dit also has commands for showing them. Tree-style conversations are possible, transferring issues from one repo to another is possible, merging issues, having issue-only repos, etc ... All possible because of this approach.
Show threadHallå Kitteh
@musicmatze Oh yes, I'm assuming there are real tools, I just appreciate a data model that can be inspected without them!

You mentioned on https://github.com/neithernut/git-dit/blob/master/doc/use-cases.md as well that issues could be easily transferred to other repos, but that would be the case only if they don't refer to (as secondary parents) actual code from the repo.

Anyway, I think the model is really interesting, and here's why:

There is a sort of tension in git-based #distbugs whether one should have issues in files along with the code or in files in a parallel branch.

When the issue lives with the code, it's really cool because you can comment on the bug as you update the code, and your commit that fixes the problem can be the commit that also closes the issue in the issue data.

When the issue lives in its own branch, it becomes unproblematic to have an issue that affects several code branches, and the discussion can be kept in one place instead of spread out in all those branches.

With your approach, it seems you can have it both ways. The issue lives in its own commit chain, but as it contains no tree, it's trivial to merge in with a commit that fixes something, so you can still get that connection. As each issue has its own root, it's not even a problem to refer to the issue from several code branches.

The space has felt quite abandoned for some time, I've been using the #bugseverywhere version from 2013, but I've been hoping that something more would happen in the field, especially tying web issues into the whole thing. It sounds like creating issues is on the roadmap for git-dit-wui?

I'll definitely look at what your tools can do. Thanks for your work!

And now I noticed that you're actually the one who updated the dist-bugs page. Good. Good. :-)

I think @joeyh and @liw might be interested to hear about #gitdit also.
neithernut/git-dit

git-dit - Decentralized Issue Tracking for git

Mar 16, 2018 at 8:39pmWeb
Show threadHallå KittehMar 16, 2018
@musicmatze @liw @joeyh Added git-ssb-web / git-ssb / ssb-issues to https://dist-bugs.branchable.com/software/ , as I noted with surprise that I had not already done so. :-)
software