Learn to use email with git! Patch Workflows - Ry’s Git Tutorial - RyPress – Another good blog post on working with Git patches via Email as well as applying them. – The key point (I think) is that you need to grab the entire contents of email email in order in order to pipe the contents into git am - – Hmmm 🤔 – I think we can do better than this…

@prologic@twtxt.net This patch workflow looks complicated for no reason to me, it also leave everything to a maintainer to handle privately before touching the public repo.

Maybe a branch based approach like the one used in GitHub/Lab/tea is simpler but still doable? Maybe as part for legit fork?

@justamoment@twtxt.net I agree, the patch workflow is a bit complicated (especially for new users) and I find it a bit unfriendly too. Having to switch from an Email client to Command-line just to manage reviews and applying patches kind of sucks IMO. – Some nice way to manage incoming changes and communicate reviews and easily applying those changes would be nicer. – I even had this stupid idea of pushing patches to a special endpoint that create a new Twt in a per-repo Twtxt feed with a link to the “patch” (via a Web UI) and then you can communicate feedback over your own feeds 🤣 – Finally a “patch” is either #approved or #rejected and patch manager can look for those tags in the thread and deal with the UI appropriately.

@prologic@twtxt.net Oh, cool and the feed is in the repo so you can host it together?

Things like git-notes might work with it?

@justamoment@twtxt.net Hmmm not sure 🤔

@prologic@twtxt.net maybe keeping the management in git and using emails just for notification could be better?

@justamoment@twtxt.net Hmmm so there isn’t a lot you can do with plain Git itself. Even patches sent via email are basisally out-or-band at that point.

@prologic@twtxt.net so a web UI is the only way (or a cli version that act similarly)?

@justamoment@twtxt.net Well what I mean to say is that git itself basically just houses some client-side “Metadata” about the repository and a bunch of objects that make up the contents and revision history. For example, there is a special file called .git/description that you can edit and there’s even git branch --edit to edit a branch’s description. But none of that is useful beyond a local client. That is to say, if you git clone or git push none of that information is published anywhere or made available to anyone else.

So Git’s “distributed data” is limited to well basically its revision history and series of objects I guess? 🤔

@prologic@twtxt.net But if we edit those on a remote repo then we can use it as a public description and when cloned you don’t need to care for it, right?

@justamoment@twtxt.net Yup pretty much. That’s what I’m thinking here… So the Web UI we build need to support IndieAuth I think (well it would be nice if it did I think) so we can manage repos… Repo descriptions can be stored/retrieved from .git/description – Likewise we can probably do something with SSH keys like storing the keys permitted for “write” access in .git/authorized_keys. What else? Hmmm 🤔

@prologic@twtxt.net What are the functionality we need?

I can see those:

• hosting
  
• bug tracking
  
• code reviews
  
• forking (i guess?)
  
• SSH
  
• push / pull (it’s read only now, right?)

@justamoment@twtxt.net I guess we start with:

• An interface to manager repos
  
• Support for git push over SSH with key management
  

What already works (mostly):

• Hosting
  
• Cloning via git clone over HTTP/SSH
  

What still needs consideration/experimentation:

• Code reviews
  
• Issue tracking

@prologic@twtxt.net ok, for interface what do you mean exactly? Are you talking about editing the repo?

About the web interface, I’d suggest to use REST API as the main interface regardless of where it’s built, so you can use them both on client and server side with the same data structure and available actions.

For the client side of any external scripting or custom web clients you have pure data to work with, if on the server side you have the same structs to build the HTML.

This helps us avoid having to work on both in parallel like with Yarn.social and leaving one side behind the other.

@justamoment@twtxt.net Can we still maintain a nice SSR (Server-side Rendered) UI though? This is something I never quite managed to “get right”, it would be nice to not have any Javascript (or ever little) for the UI but to still power the SSR and API with the same data structures (which is what I think you’re talking about?)

@prologic@twtxt.net exactly, exposed as a struct and functions (for actions) in a dedicated layer, then the API would have GET from structs and POST for functions, on server you render html the same way, structs in templates and POST for actions.

A way to have them seamlessly would be to handle the same page with content-type but maybe it’s an overkill for this kind of project.

@justamoment@twtxt.net Yeah I have a few ideas for how to structure this, but I’ve never seen anyone do it, probably because these days everyone just does this React shit™ 🤣 Gotta give this a try though… 🤔

@prologic@twtxt.net actually with next.js it does that on the server but it’s not quite what I’m thinking, you should find examples on cli apps for remote services or modular projects with the server side UI as a separate component.

@justamoment@twtxt.net Yup 👌 I’m going to experiment on someyhing a bit contrived add aee what pattern I can come up with 🤞

@prologic@twtxt.net what I recommend is a dedicated layer for data fetching and manipulation, and call it from where you need it.

By simply serializing the data via API and as raw data on server templates.

@justamoment@twtxt.net So, we’ll build a few data models that represents data we need to store and mutate and some logic to fetch that data and perform actions on it. Then an API layer will use that and serialise as either a JSON RPC API or JSON Rest API. Another layer will call the same code to fill out template contexts and render templates. Does this sound about right? 🤔

@prologic@twtxt.net that’s right, do you call the JSON RPC from the server rendering or directly from a middle layer (to keep in Go)? I see both as good.

@justamoment@twtxt.net Yeah I’m kind of thinking that the JSON API / REST API + SSR Templating calls a “middle” layer. In other words, abstract out the actual data handling and logic with interfaces that can be used for a real response directly (content negotiated) or rendered with some HTML templates.

@prologic@twtxt.net this would allow super flexible extensions, good going!👌

@justamoment@twtxt.net Cooool, so now I just gotta iterate on a few patterns and see what works best and get your opinion on it 😅

@prologic@twtxt.net sure, I’m going to make a static mock of the interface from scratch, while thinking on the general features we’ve talked about.

@justamoment@twtxt.net Sounds good! 👌