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.

Development sleeps right now, which is really unfortunate. There is a number of unresolved issues, despite the software is usable today.

A failed thesis

My friend and I proposed a bachelors thesis at our university for writing a web-viewer for git-dit. Because we’re both master students, we also offered to supervise this thesis.

In the last semester, the thesis was assigned and I was happy when it started. Today (or rather a few days ago) I was not that happy anymore, because I got the end-result. I was able to compile it (yay), but after starting it, I was not even able to open the web page because I did not know which port to use.

After looking at the source, I was able to figure that part out. Unfortunately, everything I tried to do via the web frontend failed (as in nothing happened). I was not able to see any issues or anything else. Only viewing the git configuration was possible - but that’s the least thing I cared about.

So I figured: How hard can it be? If a bachelor student has half a year time,… it must be hard? No, I guess not.

Lets do that!

So I started my own git-dit-web viewer. And I tracked the time it took to implement it.

I mean, how hard can it be? I am not a web-dev at all, I have zero experience with Rust web frameworks, I never touched one. I have no experience with CSS (only that view bits I used for this blog) and of course I also have no experience with JS.

But how hard can it be?

Turns out: It is not hard at all. I’m proud to present the first prototype, after 11 hours of implementation time:

$ time sum :week git-dit-wui

Wk  Date       Day Tags           Start      End    Time    Total
--- ---------- --- ----------- -------- -------- ------- --------
W11 2018-03-15 Thu git-dit-wui 14:00:00 16:43:35 2:43:35
                   git-dit-wui 20:31:00 23:52:04 3:21:04  6:04:39
W11 2018-03-16 Fri git-dit-wui 11:23:39 14:12:56 2:49:17
                   git-dit-wui 15:45:16 17:58:47 2:13:31  5:02:48

                                                         11:07:27

What does not work yet

Of course, this is only the first prototype. The following things do not work yet:

  • Filtering issues for open/closed or other metadata
  • Showing issues which were opened by one specific author
  • Show messages as tree (currently linear by timestamp)
  • Graph for issues-per-date (nice-to-have)
  • Showing commits
  • Automatically detecting git hashes in messages and linking to the appropriate issue/commit
  • Abbreviating git hashes in messages and everywhere else
  • Configuration
    • Port
    • Repository path
    • Readonly/RW
  • Error handling: if things go wrong, we should show an error page rather than nothing

What does work

But some things also work, of course:

  • Messages are rendered as markdown
  • Listing all issues (with some metadata)
  • Showing an issue (including replies)
  • Showing single messages
  • Landing page with statistics about issues

And it looks rather good (thanks to the bulma CSS framework) despite me beeing a CLI-only guy without web-dev experience.

Screenshots

Some screenshots showing the issues in the git-dit repository.

The landing page The issue listing page Showing a single issue

Conclusion

Of course I open-sourced the code on github and licensed it as AGPL-3.0.

So it can be done. I’m not quite sure what the student did in 6 months time he had for implementing this.