Own your Git repositories; a concept for IndieWeb-replacement of GitHub features

Drawing: anime-styled girl with pink hair and yellowish-green eyes, with flowers in transgender flag colors around and hearts painted on right cheek with lesbian flag colorsVika
    Tagged:
  • GitHub
  • IndieWeb
  • ownyourdata

I kinda like hosting my own Git repositories on my own premises. It gives me a sense of security; since nobody can access the code without my permission. With my current setup (Gitolite+cgit) I mark repositories as public by writing them in the config like this:

repo pyindieblog
    RW+     =   vika
    R       =   @all
    config gitweb.owner = Vika
    config gitweb.description = "IndieWeb-enabled CMS powered by Python"

This means that the repo will be readable for any user having SSH access (currently only me!) and it'll be posted in the projects.list file which lets cgit know this is something I would like to be public.

GitHub feature set

GitHub is not only Git. It is marketed as a "social coding tool" and also allows for:

  • Issues
  • Pull requests (the name of which could remind someone of git request-pull)
  • Comments on commits and changes

There are certainly more things, but let's focus on these, as these are the "social" features of GitHub, and these are the most widely known.

Mapping this to IndieWeb

Issues

We do have issue posts on IndieWeb! They're kinda raw, but they're described on the wiki. I propose something like this:

  1. Have source code pages accept Webmentions
  2. Have an "Issues" page that aggregates webmentions with, e.g. u-issue-of link
  3. Have the webmention endpoint process Salmentions correctly

The issue threads will be posted to the repo, and salmentions would allow for threads to be started.

Pull requests

Pull requests on GitHub are actually issues. What if we go the similar way? Have a new microformat, h-pull-request with the following properties:

  • u-url - the URL from which to pull
  • p-start - the starting commit that needs to be present in the upstream
  • p-end - the branch, tag or commit hash that is the end. Defaults to HEAD if not present.

This is inspired by the git request-pull command, which I think everyone forgot about.

On the receiving side, such a webmention could have a button to merge the changes instantly, triggering a pull and an automatic merge if possible. Or the repo maintainer could just manually pull the downstream repo and merge it manually.

Comments on commits

By far the easiest one. Send a webmention to the page describing the commit, optionally with a fragment URL pointing to the lines you're interested in.

Implementing

Sadly, I have no working implementation of this yet - this is purely brainstorming. But maybe I'll do one! Who knows? For that, I'll probably need to fork cgit or write my own git repo visualizer responding to HTTP requests. The last one will probably be better.