repos / git-pr

commit

2765a83

parent

4a84a43

author

Eric Bower

date

2024-07-05 22:42:29 -0400 EDT

docs: readme

 1@@ -48,7 +48,7 @@ account and then login. This adds quite a bit of friction for a self-hosted
 2 solution, not only for an external contributor, but also for the code owner who
 3 has to provision the infra. Often times they also have to fork the repo within
 4 the code forge before submitting a PR. Then they never make a contribution ever
 5-again and keep a forked repo around forever. That seems silly.
 6+again and a forked repo lingers. That seems silly.
 7 
 8 # introducing patch requests (PR)
 9 
10@@ -58,7 +58,11 @@ limitations imposed by the email protocol. Further, we want the primary workflow
11 to surround the local development environment. Github is bringing the IDE to the
12 browser in order to support their workflow, we want to flip that idea on its
13 head by making code reviews a first-class citizen inside your local development
14-environment.
15+environment. This has an interesting side-effect: the owner is placed in a more
16+collaborative role because they must create at least one patch to submit a
17+review. They are already in their local editor, they are already creating a git
18+commit and "pushing" it, so naturally it is easier to make code changes during
19+the review itself.
20 
21 We see this as a hybrid between the github workflow of a pull request and
22 sending and receiving patches over email.
23@@ -67,9 +71,11 @@ The basic idea is to leverage an SSH app to handle most of the interaction
24 between contributor and owner of a project. Everything can be done completely
25 within the terminal, in a way that is ergonomic and fully featured.
26 
27+The web view is mostly for discovery.
28+
29 Notifications would happen with RSS and all state mutations would result in the
30-generation of static web assets so it can all be hosted using a simple file web
31-server.
32+generation of static web assets so the web views can be hosted using a simple
33+web file server.
34 
35 ## format-patch workflow
36 
37@@ -77,7 +83,7 @@ server.
38 # Owner hosts repo `noice.git` using github
39 
40 # Contributor clones repo
41-git clone git@github.com:user/noice.git
42+git clone git@github.com:picosh/test.git
43 
44 # Contributor wants to make a change
45 # Contributor makes changes via commits
46@@ -103,8 +109,8 @@ ssh pr.pico.sh pr close 1
47 # Owner can accept a pr:
48 ssh pr.pico.sh pr accept 1
49 
50-# Owner can cleanup PR:
51-ssh pr.pico.sh pr print 1 | git am -3
52+# Owner can prep PR for upstream:
53+git rebase -i origin/main
54 
55 # Then push to upstream
56 git push origin main
57@@ -116,7 +122,7 @@ The fundamental collaboration tool here is `format-patch`. Whether you a
58 submitting code changes or you are reviewing code changes, it all happens in
59 code. Both contributor and owner are simply creating new commits and generating
60 patches on top of each other. This obviates the need to have a web viewer where
61-the reviewing can "comment" on a line of code block. There's no need, apply the
62+the reviewer can "comment" on a line of code block. There's no need, apply the
63 contributor's patches, write comments or code changes, generate a new patch,
64 send the patch to the git server as a "review." This flow also works the exact
65 same if two users are collaborating on a set of changes.
66@@ -135,8 +141,15 @@ code; they cannot be ignored or else they will be upstreamed erroneously.
67 
68 # roadmap
69 
70-- Guide for setting up `git-pr`
71-- PR build steps (e.g. check that a patch can be cleanly applied)
72+> [!IMPORTANT]\
73+> This project is being actively developed and we have not reached alpha status
74+> yet.
75+
76+- Publish demo video
77+- PR should be displayed as an event log
78+- Guide for self-hosting `git-pr`
79+- **Alpha status**
80 - Git remote for repos
81+- PR build steps (e.g. check that a patch can be cleanly applied)
82 - Review patch inline (edit patch directly with comments `# xxx` then reupload)
83 - TUI