-----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 <firstname.lastname@example.org> To: REDACTED Subject: Git web UI Date: Tue, 10 Dec 2019 02:53:21 +0100 Message-ID: <email@example.com> 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 . 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 : 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 , 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 . 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 : https://git.spacekookie.de/octopus/about/ : 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 . 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  when one handler is used on multiple routes. I made a (poor man's) patch  for it which I didn't submit due to lack of time and energy. I did submit another patch  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  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  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  https://github.com/http-rs/tide/blob/master/src/request.rs#L279  https://github.com/vladan/tide/commit/08ad0100e2b8666b749d24ab996d9b9e4d161307  https://github.com/http-rs/tide/pull/468  https://github.com/http-rs/tide/pull/603  https://pksunkara.com/posts/state-of-routing-in-rust/