Own your Git repositories; a concept for IndieWeb-replacement of GitHub features
- Pretty permalinks for this post:
- https://fireburn.ru/posts/1568652213
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:
- Have source code pages accept Webmentions
- Have an "Issues" page that aggregates webmentions with, e.g.
u-issue-of
link - 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 pullp-start
- the starting commit that needs to be present in the upstreamp-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.