upleb.uk

Public git repos — served from a NIP-34 GRASP relay at git.upleb.uk

summaryrefslogtreecommitdiff
path: root/34.md
diff options
context:
space:
mode:
Diffstat (limited to '34.md')
-rw-r--r--34.md104
1 files changed, 90 insertions, 14 deletions
diff --git a/34.md b/34.md
index 56ede85..d35c0eb 100644
--- a/34.md
+++ b/34.md
@@ -10,7 +10,7 @@ This NIP defines all the ways code collaboration using and adjacent to [`git`](h
10 10
11## Repository announcements 11## Repository announcements
12 12
13Git repositories are hosted in Git-enabled servers, but their existence can be announced using Nostr events, as well as their willingness to receive patches, bug reports and comments in general. 13Git repositories are hosted in Git-enabled servers, but their existence can be announced using Nostr events. By doing so the author asserts themselves as a maintainer and expresses a willingness to receive patches, bug reports and comments in general, unless `t` tag `personal-fork` is included.
14 14
15```jsonc 15```jsonc
16{ 16{
@@ -25,6 +25,7 @@ Git repositories are hosted in Git-enabled servers, but their existence can be a
25 ["relays", "<relay-url>", ...], // relays that this repository will monitor for patches and issues 25 ["relays", "<relay-url>", ...], // relays that this repository will monitor for patches and issues
26 ["r", "<earliest-unique-commit-id>", "euc"], 26 ["r", "<earliest-unique-commit-id>", "euc"],
27 ["maintainers", "<other-recognized-maintainer>", ...], 27 ["maintainers", "<other-recognized-maintainer>", ...],
28 ["t","personal-fork"], // optionally indicate author isn't a maintainer
28 ["t", "<arbitrary string>"], // hashtags labelling the repository 29 ["t", "<arbitrary string>"], // hashtags labelling the repository
29 ] 30 ]
30} 31}
@@ -45,7 +46,7 @@ An optional source of truth for the state of branches and tags in a repository.
45 "kind": 30618, 46 "kind": 30618,
46 "content": "", 47 "content": "",
47 "tags": [ 48 "tags": [
48 ["d", "<repo-id>"], // matches the identifier in the coresponding repository announcement 49 ["d", "<repo-id>"], // matches the identifier in the corresponding repository announcement
49 ["refs/<heads|tags>/<branch-or-tag-name>","<commit-id>"] 50 ["refs/<heads|tags>/<branch-or-tag-name>","<commit-id>"]
50 ["HEAD", "ref: refs/heads/<branch-name>"] 51 ["HEAD", "ref: refs/heads/<branch-name>"]
51 ] 52 ]
@@ -66,13 +67,17 @@ The `refs` tag can be optionally extended to enable clients to identify how many
66} 67}
67``` 68```
68 69
69## Patches 70## Patches and Pull Requests (PRs)
70 71
71Patches can be sent by anyone to any repository. Patches to a specific repository SHOULD be sent to the relays specified in that repository's announcement event's `"relays"` tag. Patch events SHOULD include an `a` tag pointing to that repository's announcement address. 72Patches and PRs can be sent by anyone to any repository. Patches and PRs to a specific repository SHOULD be sent to the relays specified in that repository's announcement event's `"relays"` tag. Patch and PR events SHOULD include an `a` tag pointing to that repository's announcement address.
72 73
73Patches in a patch set SHOULD include a NIP-10 `e` `reply` tag pointing to the previous patch. 74Patches SHOULD be used if each event is under 60kb, otherwise PRs SHOULD be used.
74 75
75The first patch revision in a patch revision SHOULD include a NIP-10 `e` `reply` to the original root patch. 76### Patches
77
78Patches in a patch set SHOULD include a [NIP-10](10.md) `e` `reply` tag pointing to the previous patch.
79
80The first patch revision in a patch revision SHOULD include a [NIP-10](10.md) `e` `reply` to the original root patch.
76 81
77```jsonc 82```jsonc
78{ 83{
@@ -103,9 +108,66 @@ The first patch revision in a patch revision SHOULD include a NIP-10 `e` `reply`
103 108
104The first patch in a series MAY be a cover letter in the format produced by `git format-patch`. 109The first patch in a series MAY be a cover letter in the format produced by `git format-patch`.
105 110
111### Pull Requests
112
113The PR or PR update tip SHOULD be successfully pushed to `refs/nostr/<[PR|PR-Update]-event-id>` in all repositories listed in its `clone` tag before the event is signed.
114
115An attempt SHOULD be made to push this ref to all repositories listed in the repository's announcement event's `"clone"` tag, for which their is reason to believe the user might have write access. This includes each [grasp server](https://njump.me/naddr1qvzqqqrhnypzpgqgmmc409hm4xsdd74sf68a2uyf9pwel4g9mfdg8l5244t6x4jdqy28wumn8ghj7un9d3shjtnwva5hgtnyv4mqqpt8wfshxuqlnvh8x) which can be identified using this method: `clone` tag includes `[http|https]://<grasp-path>/<valid-npub>/<string>.git` and `relays` tag includes `[ws/wss]://<grasp-path>`.
116
117Clients MAY fallback to creating a 'personal-fork' `repository announcement` listing other grasp servers, e.g. from the `User grasp list`, for the purpose of serving the specified commit(s).
118
119```jsonc
120{
121 "kind": 1618,
122 "content": "<markdown text>",
123 "tags": [
124 ["a", "30617:<base-repo-owner-pubkey>:<base-repo-id>"],
125 ["r", "<earliest-unique-commit-id-of-repo>"] // so clients can subscribe to all PRs sent to a local git repo
126 ["p", "<repository-owner>"],
127 ["p", "<other-user>"], // optionally send the PR to another user to bring it to their attention
128
129 ["subject", "<PR-subject>"],
130 ["t", "<PR-label>"], // optional
131 ["t", "<another-PR-label>"], // optional
132
133 ["c", "<current-commit-id>"], // tip of the PR branch
134 ["clone", "<clone-url>", ...], // at least one git clone url where commit can be downloaded
135 ["branch-name", "<branch-name>"], // optional recommended branch name
136
137 ["e", "<root-patch-event-id>"], // optionally indicate PR is a revision of an existing patch, which should be closed
138 ["merge-base", "<commit-id>"], // optional: the most recent common ancestor with the target branch
139 ]
140}
141```
142
143### Pull Request Updates
144
145A PR Update changes the tip of a referenced PR event.
146
147```jsonc
148{
149 "kind": 1619,
150 "content": "",
151 "tags": [
152 ["a", "30617:<base-repo-owner-pubkey>:<base-repo-id>"],
153 ["r", "<earliest-unique-commit-id-of-repo>"] // so clients can subscribe to all PRs sent to a local git repo
154 ["p", "<repository-owner>"],
155 ["p", "<other-user>"], // optionally send the PR to another user to bring it to their attention
156
157 // NIP-22 tags
158 ["E", "<pull-request-event-id>"],
159 ["P", "<pull-request-author>"],
160
161 ["c", "<current-commit-id>"], // updated tip of PR
162 ["clone", "<clone-url>", ...], // at least one git clone url where commit can be downloaded
163 ["merge-base", "<commit-id>"], // optional: the most recent common ancestor with the target branch
164 ]
165}
166```
167
106## Issues 168## Issues
107 169
108Issues are Markdown text that is just human-readable conversational threads related to the repository: bug reports, feature requests, questions or comments of any kind. Like patches, these SHOULD be sent to the relays specified in that repository's announcement event's `"relays"` tag. 170Issues are Markdown text that is just human-readable conversational threads related to the repository: bug reports, feature requests, questions or comments of any kind. Like patches, these SHOULD be sent to the relays specified in that repository's announcement event's `"relays"` tag.
109 171
110Issues may have a `subject` tag, which clients can utilize to display a header. Additionally, one or more `t` tags may be included to provide labels for the issue. 172Issues may have a `subject` tag, which clients can utilize to display a header. Additionally, one or more `t` tags may be included to provide labels for the issue.
111 173
@@ -125,11 +187,11 @@ Issues may have a `subject` tag, which clients can utilize to display a header.
125 187
126## Replies 188## Replies
127 189
128Replies to either a `kind:1621` _issue_ or a `kind:1617` _patch_ event should follow [NIP-22 comment](22.md). 190Replies to either a `kind:1621` (_issue_), `kind:1617` (_patch_) or `kind:1618` (_pull request_) event should follow [NIP-22 comment](22.md).
129 191
130## Status 192## Status
131 193
132Root Patches and Issues have a Status that defaults to 'Open' and can be set by issuing Status events. 194Root Patches, PRs and Issues have a Status that defaults to 'Open' and can be set by issuing Status events.
133 195
134```jsonc 196```jsonc
135{ 197{
@@ -139,7 +201,7 @@ Root Patches and Issues have a Status that defaults to 'Open' and can be set by
139 "kind": 1633, // Draft 201 "kind": 1633, // Draft
140 "content": "<markdown text>", 202 "content": "<markdown text>",
141 "tags": [ 203 "tags": [
142 ["e", "<issue-or-original-root-patch-id-hex>", "", "root"], 204 ["e", "<issue-or-PR-or-original-root-patch-id-hex>", "", "root"],
143 ["e", "<accepted-revision-root-id-hex>", "", "reply"], // for when revisions applied 205 ["e", "<accepted-revision-root-id-hex>", "", "reply"], // for when revisions applied
144 ["p", "<repository-owner>"], 206 ["p", "<repository-owner>"],
145 ["p", "<root-event-author>"], 207 ["p", "<root-event-author>"],
@@ -150,7 +212,7 @@ Root Patches and Issues have a Status that defaults to 'Open' and can be set by
150 ["r", "<earliest-unique-commit-id-of-repo>"] 212 ["r", "<earliest-unique-commit-id-of-repo>"]
151 213
152 // optional for `1631` status 214 // optional for `1631` status
153 ["e", "<applied-or-merged-patch-event-id>", "", "mention"], // for each 215 ["q", "<applied-or-merged-patch-event-id>", "<relay-url>", "<pubkey>"], // for each
154 // when merged 216 // when merged
155 ["merge-commit", "<merge-commit-id>"] 217 ["merge-commit", "<merge-commit-id>"]
156 ["r", "<merge-commit-id>"] 218 ["r", "<merge-commit-id>"]
@@ -161,12 +223,26 @@ Root Patches and Issues have a Status that defaults to 'Open' and can be set by
161} 223}
162``` 224```
163 225
164The Status event with the largest created_at date is valid. 226The most recent Status event (by `created_at` date) from either the issue/patch author or a maintainer is considered valid.
165 227
166The Status of a patch-revision defaults to either that of the root-patch, or `1632` (Closed) if the root-patch's Status is `1631` and the patch-revision isn't tagged in the `1631` event. 228The Status of a patch-revision is to either that of the root-patch, or `1632` (_Closed_) if the root-patch's Status is `1631` (_Applied/Merged_) and the patch-revision isn't tagged in the `1631` (_Applied/Merged_) event.
167 229
230## User grasp list
231
232List of [grasp servers](https://njump.me/naddr1qvzqqqrhnypzpgqgmmc409hm4xsdd74sf68a2uyf9pwel4g9mfdg8l5244t6x4jdqy28wumn8ghj7un9d3shjtnwva5hgtnyv4mqqpt8wfshxuqlnvh8x) the user generally wishes to use for NIP-34 related activity. It is similar in function to the NIP-65 relay list and NIP-B7 blossom list.
233
234The event SHOULD include a list of `g` tags with grasp service websocket URLs in order of preference.
235
236```jsonc
237{
238 "kind": 10317,
239 "content": "",
240 "tags": [
241 ["g", "<grasp-service-websocket-url>"], // zero or more grasp sever urls
242 ]
243}
244```
168 245
169## Possible things to be added later 246## Possible things to be added later
170 247
171- "branch merge" kind (specifying a URL from where to fetch the branch to be merged)
172- inline file comments kind (we probably need one for patches and a different one for merged files) 248- inline file comments kind (we probably need one for patches and a different one for merged files)