-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
This is a forwarded e-mail from personal correspondence, archived here
for future development purposes.
- - Katharina
- -------------
From: Katharina Fey <kookie@spacekookie.de>
To: REDACTED
Subject: Git web UI
Date: Tue, 10 Dec 2019 02:53:21 +0100
Message-ID: <87h829t08e.fsf@kookie.space>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-=";
micalg=pgp-sha256; protocol="application/pgp-signature"
- --=-=-=
Feel free to e-mail me a key for you or something. Mine can be found on
my website [1]. Attached are a few pictures. To summarise my thoughts on
them, here some notes:
- - cgit is nice and simple but it's not easy to customise
- - Mainly sacks ways to make projects approachable
- - I really started liking git via e-mail as a workflow and am thinking
about how to make it more accessible/ easier to teach
- - Some modern platform features are quite neat, like a rendered graph,
contribution stats, following a repo (say via RSS) or even just
leaving a "star" as a way to say "kudos".
So out of those design guidelines I thought about how to implement
them. Again, a bit off the top of my head (this is good documentation
for myself too!):
- - Write something in Rust, with a template engine and a git server behind it
- - This software doesn't really have "accounts" and is aimed to be easy
to self host, on anything that can run Linux (i.e. very lightweight)
- - Replicate some of the more modernised language/ features:
- commits + branches, instead of "refs"?
- Easy way to get contributor stats
- Use something like linguist to gather stats on language and render
it neatly. I feel this is an overlooked feature. I think people
connect with projects based on what it's written in/ how it
works. Being able to say "hey, there's some Ruby here, maybe I can
contribute to that" makes a project feel a lot less daunting!
- - By default render a README
- - Have a page that is dedicated to onboard people (i.e. "how to
contribute?"). This could be linking to IRC/matrix channels or
mailing lists
Optional extras once the core is done, possibly as separate programs
that only hook into each other, like sourcehut:
- - CI based on mailing patches/ patchsets
- - Issue trackers based on tagging certain e-mails on the mailing list
(i.e. meant for newcomers to replace "good first issues" dynamics)
- - ... ? not sure actually, this is already plenty
Anyway, this has been brewing in my head for a week and a bit now, I'm
wondering what you think. I think this is something I could do, but it
will take quite a while. With help, especially for the front-end
things, it might move a lot quicker and be a lot nicer!
Cheers,
Kookie
[1]: https://spacekookie.de/keys.txt
- --=-=-=
-----BEGIN PGP SIGNATURE-----
iQIzBAEBCAAdFiEEU1yozzD8YhxLtnIc+XKu6iiH1UcFAl3vx5wACgkQ+XKu6iiH
1Ucn6BAApqICjfrgNM830tzqeOABo7RQdq0PMMmZFby0xdtJXaAWWtvMS/vMIutZ
g8uGTrfNotj3cujPmRnm86kHQM46YbulVuG7WN/qsmlBs0vz1KAHgpTLI0S4x+rh
6aUSTOthiLo6ts++GA05tO/Q3sIxL3ud9BQ6esXePy/tM6eaAXO4lqLPjfpGakEf
DBprzCMRrYDe4/G9JKJZPNgg9lICP4enka9MSap+4kWjM0VWo8521vznNnq04Myu
nHY/cVL0tAaEUDsiKexih7I8NVzX+YDT7am62gghQB/GG7J9MuMSEaOfktDMl/xP
9CGiUPyT2XxbJi64l2ACuMaiXgddAQsF9XxahgPwbpsAWSI89IQDlNvv1uxWVRax
jaufB3/Srw+foYvBbW0+PZlcVmhuAr5D7bvTBGJ6EyFuZj9BaSBolx5iN+016ZI0
U081u+dO0mzjVotvdPgVklJIVfLYZeqZ8kv0RK1XmX9rGavZ/vEm98dTZwMMQuwN
7pa3C9dcunfXdWWq2rjoUCbSnET6hQX6XB8rnfjCaEq1pIeT0zDFoyi34fZ3FeDK
4n+r3+fP3B9z1C0Iya50CFtPBMa5lKvwZWam1CtMBSIXHHxbik34mkgnmIhzRFlH
vj1GcArkEXh1vIiLOUcnJ8cVhPIwRpbobbA1CyjEtxdEXDjhFfo=
=R47m
-----END PGP SIGNATURE-----
Hej Katharina,
I've read quite a bit of your thoughts on git and I love it. Kudos!
I'm kind of a selfhosted git enthusiast myself :) started making this on
the side https://git.vp.mk/ui/git-social.git/master/tree ... got stuck
on wrong library choices (tide) and the whole api + wasm thing was a
tryout, didn't really mean to go further with it. I plan on rewriting it
(any time soon) with templates rendered on the server (in hyper/warp, or
actix if nothing else works) and making it a-la cgit, with code and
contribution stats and maybe other niceties github / gitlab have. I
actually planned to include much of the things you mentioned here!
This message is just to let you know this
(https://git.sr.ht/~vladan/git-social) exists.
I'll also continue to follow your git posts with great interest :)
Wish you all the best,
Vladan
P.S.
I know you're not up for federation (activity pub) for submitting
patches, but I believe it's the way to go for people to collaborate in a
decentralized manner on a platform / service they can host themselves,
it would mean a lot for me if such a service existed ...
I also support your opinion on sending patches by email, but as you've
discussed, very few people make use of it, except on some projects ofc,
and it can be a tedious process all in all. Looking forward for some new
findings on that field!
Hey Vladan,
> I've read quite a bit of your thoughts on git and I love it. Kudos!
Thanks! It's hard to communicate things sometimes, and I hope I'll
still get better at it!
> I'm kind of a selfhosted git enthusiast myself :) started making this on > the side https://git.vp.mk/ui/git-social.git/master/tree ... got stuck > on wrong library choices (tide) and the whole api + wasm thing was a > tryout, didn't really mean to go further with it. I plan on rewriting> it [...]
Oh interesting! I actually started working on basically this again
myself recently. I call it octopus [1], and it's using tide and
templates x)
I'm not neccessarily sold on tide yet, especially because it seems to
have a bug that prevents me from continuing at the moment [2]. I guess
actix just felt a bit overkill, but would be what I'd switch to
otherwise (not a fan of warp).
Anyway, the idea of octopus was to keep the core pretty small, and
having it possible to hook other things into it, such as accounts, ssh
management (instead of relying on local server accounts, etc). I would
even be open to having a plugin handle some other form of pulling
mechanism via federation, as long as the core was still able to
integrate into some mailing list based workflow).
Maybe we could pool our resources here, seeing as I think we want very
similar things.
~k
[1]: https://git.spacekookie.de/octopus/about/
[2]: https://github.com/http-rs/tide/issues/593
Hej,
Thanks for the reply! (and sorry for the wall on tide)
> It's hard to communicate things sometimes, and I hope I'll
> still get better at it!
I think you're doing really really good, according to my own standards
at least :)
Keep at it!
> Maybe we could pool our resources here, seeing as I think we want very
> similar things.
Yes!! :)
Would definitely love this!
> I'm not neccessarily sold on tide yet, especially because it seems to
> have a bug that prevents me from continuing at the moment [2]. I guess
> actix just felt a bit overkill, but would be what I'd switch to
> otherwise (not a fan of warp).
I honestly haven't tried anything except tide, went in warps direction
since it seemed smaller than actix, but I'm still undecided. Will figure
out soon anyways.
If you have the will, I'd love to hear your thoughts on warp so I evade
the pitfalls you were in :)
Re tide: I've hit bumps more than once, at the end forked it and
maintained it for a while, but seemed a lot of work to get into the
whole thing.
E.g. it panicks [1] when one handler is used on multiple routes. I made
a (poor man's) patch [2] for it which I didn't submit due to lack of
time and energy. I did submit another patch [3] which removes the
creation of two default middlewares, logging and cookies, which causes
e.g. multiple log entries if you have nested routes. I don't think it
will be merged since the authors want both middlewares by default, but
(in short) feelings are mixed and this is kept ignored.
All in all, IMHO tide has great potential, but seems to be defocused
from usability and focuses more on features and perfection of design.
For me, that makes tide pretty hard to use in myproject and will cool it
down until it reaches a stage where it can be actually used without
obstacles on more or less every step.
You OTOH might get what you need [4] without breaking too much sweat :P
... but keep a lookout for nested routes and using one handler on
multiple routes, which are issues that still haven't be en resolved.
It's also missing wildcard / regex routes ... I wanted e.g.
"/:owner/[\w-]+\.git" for https cloning and "/:owner/:repo" for
browsing, but with the current state of things it's impossible to get
anything even close to this.
I found a good resource on routing [5] in rust web frameworks. I'm
thinking it may serve you some good as well, and it uses git urls for
the examples :)
> Anyway, the idea of octopus was to keep the core pretty small, and
> having it possible to hook other things into it, such as accounts, ssh
> management (instead of relying on local server accounts, etc).
> I would even be open to having a plugin handle some other form of pulling
> mechanism via federation, as long as the core was still able to integrate
> into some mailing list based workflow).
My thoughts also go in that direction. Having a small simple core with a
fair plugin system so things don't blow out of proportions. Still
thinking about this actually, haven't figured it out thoroughly, but
let's leave this for another discussion, it's really broad and I'm
reluctant to write two walls in one message.
Hope this helps some,
Vladan
[1] https://github.com/http-rs/tide/blob/master/src/request.rs#L279
[2]
https://github.com/vladan/tide/commit/08ad0100e2b8666b749d24ab996d9b9e4d161307
[3] https://github.com/http-rs/tide/pull/468
[4] https://github.com/http-rs/tide/pull/603
[5] https://pksunkara.com/posts/state-of-routing-in-rust/