dashboard / git-pr / fix: use eventlog time for pr details #8 rss

accepted · opened on 2024-07-22T16:07:15Z by jolheiser
Help
# add changes to patch request
git format-patch main --stdout | ssh pr.pico.sh pr add 8
# add review to patch request
git format-patch main --stdout | ssh pr.pico.sh pr add --review 8
# remove patchset
ssh pr.pico.sh ps rm ps-x
# checkout all patches
ssh pr.pico.sh pr print 8 | git am -3
# print a diff between the last two patches in a patch request
ssh pr.pico.sh pr diff 8
# accept PR
ssh pr.pico.sh pr accept 8
# close PR
ssh pr.pico.sh pr close 8

Logs

exelotl created pr with ps-14 on 2024-07-20T15:02:56Z
erock reviewed pr with ps-15 on 2024-07-21T15:50:45Z
erock changed status on 2024-07-21T15:50:45Z {"status":"reviewed"}
erock changed status on 2024-07-21T15:51:14Z {"status":"accepted"}

Patchsets

ps-14 by exelotl on 2024-07-20T15:02:56Z
Range Diff ↕ rd-15
-: ------- > 1: e082026 LGTM
1: 3ba22c2 = 2: e082026 docs: fix typo / minor rewording in readme
ps-15 by erock on 2024-07-21T15:50:45Z

Patchset ps-14

docs: fix typo / minor rewording in readme

Jeremy Clarke
2024-07-20T14:59:21Z
README.md
+5 -5
Back to top

docs: fix typo / minor rewording in readme

README.md link
+5 -5
 1diff --git a/README.md b/README.md
 2index ee341c4..d8182e6 100644
 3--- a/README.md
 4+++ b/README.md
 5@@ -124,11 +124,11 @@ git push origin main
 6 # Done!
 7 ```
 8 
 9-The fundamental collaboration tool here is `format-patch`. Whether you a
10-submitting code changes or you are reviewing code changes, it all happens in
11-code. Both contributor and owner are simply creating new commits and generating
12-patches on top of each other. This obviates the need to have a web viewer where
13-the reviewer can "comment" on a line of code block. There's no need, apply the
14+The fundamental collaboration tool here is `format-patch`. Whether you are
15+submitting code changes or reviewing them, it all happens in code. Both
16+contributor and owner are simply creating new commits and generating patches
17+on top of each other. This obviates the need to have a web viewer where the
18+reviewer can "comment" on a line of code block. There's no need, apply the
19 contributor's patches, write comments or code changes, generate a new patch,
20 send the patch to the git server as a "review." This flow also works the exact
21 same if two users are collaborating on a set of changes.