repos / git-pr

commit

b135780

parent

5ee4d60

author

Eric Bower

date

2024-04-29 10:38:37 -0400 EDT

exposition

 1@@ -109,12 +109,49 @@ cat my_comment.md | git.sh comment noice/1
 2 # rinse and repeat
 3 ```
 4 
 5+The fundamental collaboration tool here is `format-patch`. Whether you a
 6+submitting code changes or you are reviewing code changes, it all happens in
 7+code. Both contributor and owner are simply creating new commits and generating
 8+patches on top of each other. This obviates the need to have a web viewer where
 9+the reviewing can "comment" on a line of code block. There's no need, apply the
10+contributor's patches, write comments or code changes, generate a new patch,
11+send the patch to the git server as a "review." This flow also works the exact
12+same if two users are collaborating on a set of changes.
13+
14+This also solves the problem of sending multiple patchsets for the same code
15+change. There's a single, central Patch Request where all changes and
16+collaboration happens.
17+
18+We could figure out a way to leverage `git notes` for reviews / comments, but
19+honestly, that solution feels brutal and outside the comfort level of most git
20+users. Just send reviews as code and write comments in the programming language
21+you are using. It's the job of the contributor to "address" those comments and
22+then remove them in subsequent patches.
23+
24 ## branch workflow
25 
26 It's definitely possible for us to figure out a way to let the contributor
27 simply push a branch and create a patch request automatically, but there are
28 some rough edges to figure out there in order for it to work well.
29 
30+The flow would be virtually the same as `format-patch` except the contributor
31+would push a branch and we would automatically create a `format-patch` against
32+the base branch and then funnel it into the Patch Request. We don't want
33+external contributors to be able to push branches into the owner's git remote
34+because that has all sorts of opportunities for abuse. Instead we need to figure
35+out how to either fork the owner's repo and let the contributor push to that
36+fork seamlessly, or we just generate patchsets based on the contributor's branch
37+and the owner's base branch.
38+
39+This flow probably feels the most comfortable for Github users, but technically
40+more difficult to implement. Right out of the gate we need to know what base
41+branch the contributor wants to merge into. Then we need to figure out how to
42+perform reviews and followup code changes.
43+
44+This feels feasible, but technically more difficult. Further, I still want to
45+support patchsets via `format-patch` because it is a very elegant solution for
46+simpler changes.
47+
48 # web interface
49 
50 The other idea is to make the git web viewer completely static. Whenever an