diff --git a/README.md b/README.md index 5b7b58a..7ab3a98 100644 --- a/README.md +++ b/README.md @@ -1,6 +1,114 @@ -# Patchodon +# Patchodon -- send `git` patchsets via Mastodon -Like pull requests or merge requests, but over a federated medium (via Mastodon API). +Patchodon is a tool for federated distribution of "pull requests" for git. -(TODO) +In ye olde times (and in linux development and related places), the "pull +requests" are done simply via sending patches through e-mail. Coordinating some +discussion atop of that is doable in a semi-distributed manner, typically the +discussion is done via a mailing list, and you need a mailing list service that +manages the mail forwarding to everyone involved, and preferably archives. + +Patchodon is doing a similar workflow of sending the patches directly to the +"target", but it uses [Mastodon](https://joinmastodon.org/) network as an open +communication medium, instead of the mailing lists. + +In short, the workflow is as follows: + +1. The patch author runs `git format-patch ... | patchodon post`, which uploads + the patches to a mastodon thread and gives the URL to the "head" status +2. All commits in the patch receive their own status, so that people can freely + comment on them and generally organize on getting the code in a good shape + for merging. If space allows, the commit statuses have a piece of commit + message and/or diff stats, so that people can sensibly comment on individual + pieces of the patchset. +3. The actual commit data are currently uploaded to + [dpaste](https://dpaste.com) via their API, as that is a slightly better + place for posting "exact" patches. +4. The owner of the target repository runs `pathodon get + https://mastodon.example/@some_user/1234567890 | git am`, which retrieves + the patches from the thread and applies them into a branch in the local + repository. The actual merging happens locally, like with other federated + git workflows. + +## Installation and setup + +`patchodon` executable should work with any Python 3; simply put it into a +directory in your `PATH`. + +You may need `requests` and `html2text` which can be downloaded via +distribution packages, or with `pip` (see `requirements.txt`). + +## Basic usage + +To get patchodon working, you will need to give it (limited) access to your +Mastodon instance, via an access token: +- navigate to Preferences → Development +- there, create a new application +- the application needs the following scopes: + - `read:search` and `read:statuses` for running `patchodon get` + - `write:statuses` for running `patchodon post` +- copy the access token and put it into the patchodon config. + +The patchodon config in your `~/.patchodon.ini` should be filled in to look +roughly like this: +```ini +[patchodon] +instance_url=https://your.mastodon.instance.example/ +api_token=xxxxxx_the_token_you_got_from_mastodon_application_settings_xxxxxxx +``` +(You can also set the instance and token via command line, but that's much less +convenient for daily use.) + +### Sending patches + +Assume you have branched off the `main` branch in your repository, and you want +to send the patches to someone called "JohnDoe" on the target instance: +```sh +$ git format-patch main | patchodon post -r @JohnDoe -s 'this is the patches we talked about last week' + +https://your.mastodon.instance.example/@someGuy/34592345923 +``` +`-r` stands for "recipient" (all statuses are going to get tagged with that) +and `-s` stands for subject (the head status is going to include that text). +The URL is the "head" of the patch set that contains the metadata (mainly the +complete hash of the patches) that allow people to safely reassemble your +patchset. + +### Receiving patches + +John Doe will see the status, give it a rough examination, see if other +developers commented anything in the patch series, and if all seems OK, they +will pull the changes into a new branch as follows: +```sh +$ git checkout -b someguy/the-patches-we-talked-about +$ patchodon get https://your.mastodon.instance.example/@someGuy/34592345923 | git am +``` + +And that's it -- the patch was discussed, and got safely transferred to the +destination. + +## Disclaimers and dangers + +- Note that the rules of some Mastodon instances may prevent you from using + this. Using scripts to post multiple statuses may be considered as an + automated use, and might be viewed as very undesirable by both users and + admins. **Please verify, very carefully, that your instance is OK with this + kind of supervised, semi-automated use.** It's always best to check with the + admins before you start spamming the patches around. +- Patchodon makes some mild effort to prevent others from injecting code into + your published patch series. Most notably, all patches are hashed, the hashes + are hashed together to form a "full hash", and that is required to match + perfectly before `patchodon get` outputs the code into your git. Regardless, + you should always be aware of the security implications of downloading things + from the Internet and piping them into git-am. + +## TODOs + +You might have noticed that this is far from complete. The following features +are on the TODO list: + +- support for different pastebins (possibly providing more privacy) +- status visibility configuration +- dpaste retention configuration +- likely a better default hash function than SHA1