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