Pain points in Git's patch flow

[ZheNing Hu]

Haaaa, everyone, I am this example :)
Sorry I haven't checked these mails cc to me for a long time.

Junio C Hamano <gitster at pobox.com> 于2021年4月17日周六 上午3:50写道：
>
> Jonathan Nieder <jrnieder at gmail.com> writes:
>
> >  3. Do you think patchwork goes in a direction that is likely to help
> >     with these?
>
> So here is a real-life example.
>
> Let's say somebody is looking at a "gentle ping" [*1*]
>
> znh> The patch seems to have fallen into the crack.
> zhn> Jeff and Junio, willing to help?
>
> How would we figure out what happened to the patch today without
> visiting patchwork would be:
>
>  1. Visit the message at lore.kernel.org/git/ [*1*]
>
>  2. Notice that it is a response to a message, and click the link to
>     be taken to [*2*]
>
>  3. Notice that nobody commented on the patch.
>
>  4. Type "f:zhening ref-filter" to the search box and search, with
>     suspicion that this was an updated version of something.
>
>  5. Click one of them in the result [*3*]
>

> I can see #3 would immediately become obvious, and I hope #4-#5
> would become unnecessary.
>

Here are my thoughts:

For the reviewers like Junio, after missing a new patch iteration, need to
review the past history to find the correct patch and related comments
from other reviewers. Just like I once read a github blog saying that
"patch" is also a special object in git. I would like to have a "new" tool
 which can link multiple related patches and comments.

1. Coder need Reviewers' help.
2. This new tool will obtained multiple different patch versions
automatically
or coder provided those pathes versions links.
3. This tool will analyze the differences between multiple versions, get all
the reviewers comments and coder comments related to the "patch stream",
organize it into "patch graph".
4. The tool will notify the reviewer(by email or something else) and show
the links
and patch graph or patch range-diff.And It can visualize the entire patch
process,
 It’s best that comments from different people can be displayed on one page.

In order to be more accurate, I made a picture [*1*].

Using this new tool, reviewers can choose to see or not see the range-diff
and diff in multiple different patch versions, Instead of the range-diff
automatically sent by GGG. When my second patch processing was greatly
changed from the previous one, I have to rebuild a new branch and create a
new
PR, this is my pain point.

> Anything else?
>
> At steps #6 and #7, there is human judgment involved that may not be
> automatable, but would there be some mechanism to make it easy to
> help these steps if the user visits patchwork (instead of staying
> in my newsreader or web interface to the lore archive)?
>
> I am of course not expecting to automate step #9 ;-)  It would be
> nice though.
>
> Thanks.
>
>
> [References]
>
> *1* https://lore.kernel.org/git/CAOLTT8Tis5Yjg8UR0c-i0BnqiFQvLXvDgxUQJ-
WcP6jjQPu9cQ at mail.gmail.com/
>
> *2* https://lore.kernel.org/git/pull.928.git.1617975348494.
gitgitgadget at gmail.com/
>
> *3* https://lore.kernel.org/git/pull.927.v2.git.1617809209164.
gitgitgadget at gmail.com/

Thanks!

*1*
https://github.com/adlternative/git/blob/pic/git-patch-pain-point-solve-idea.png

--
ZheNing Hu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ozlabs.org/pipermail/patchwork/attachments/20210501/bf2a3814/attachment.htm>