Pain points in Git's patch flow
Son Luong Ngoc
sluongng at gmail.com
Fri Apr 16 01:45:54 AEST 2021
I'm not a regular contributor but I have started to subscribe to the
Git's Mailing List recently. So I thought it might be worth sharing my
personal view on this.
After writting all the below, I do realize that I have written quite a
rant, some of which I think some might consider to be off topic. For
that, I do want to appologize before hand.
Tue, Apr 13, 2021 at 11:13:26PM -0700, Jonathan Nieder wrote:
> Those four are important in my everyday life. Questions:
> 1. What pain points in the patch flow for git.git are important to
There are several points I want to highlight:
1. Issue about reading the Mailing List:
- Subscribing to Git's Mailing List is not trivial:
It takes a lot of time to setup the email subscription. I remember
having to google through a few documents to get my subscription
- And even after having subscribed, I was bombarded with a set
of spam emails that was sent to the mailing list address. These spams
range anywhere from absurd to disguising themselves as legitimate
users trying to contact you about a new shiny tech product.
2. Issue about joining the conversation in the Maling List:
- Setting up email client to reply to the Mailing List was definitely
not trivial. It's not trivial to send a reply without subscribing to
the ML(i.e. using a Header provided from one of the archive).
The list does not accept HTML emails, which many clients
use as default format. Getting the formatting to work for line
wrapping is also a challenge depends on the client that you use.
- It's a bit intimidating to ask 'trivial questions' about the patch and
create 'noise' in the ML.
3. Isssue with archive:
- I don't find the ML archive trivial for new comers. It took me a bit
of time to realize: 'Oh if I scroll to bottom and find the "Thread
overview" then I can navigate a mailing thread a lot easier'.
- The lack of labeling / categorization that I can filter while browsing
through the archive make the 'browse' experience to be quite
unpleasant. Search is one way to do it, but a new comers would not be
knowledgable enough to craft search query to get the archive view just
right. Perhaps a way to provide a curate set of categories would be
- Lost track of issues / discussion:
A quick example would be me searching for Git's zstd support
and got next to no relevant result. However if I were to query
then a very relevant thread from Peff appeared. I think this could be
avoided if the search in ML archive do more than just matching exact
4. Lack of way to run test suite / CI:
It would be nice if we can discuss patches while having CI result as
part of the conversation. Right now mostly I see that we have to
manually running benchmarks/tests and share the paste the results.
But for folks who don't have a dev environment ready at hand (new
comers, during travel with only phone access), it would be nice to
have a way to run tests without a dev environment.
This was mostly solved in the context of works spent on Github's
Action Workflow. But if we are discussing about pure patch flow, this
is a miss.
> 2. What tricks do you use to get by with those existing pain points?
- I had to invested a lot of time into setting up a set of Gmail search
filter. Move mails with topics that Im interested in into a special
tag while the rest into archive. Regularly check if anything
interesting went to archive by accident.
- I had to setup Mutt + Tmux to have a compatible experience sending
replies like this one.
- All the patches I have submitted were through
and it was not directly trivial to get permission to send email from a
- Spending time reading git blame / git log / commit message helps
identifying the keywords I need to refine my search result in the ML
archive. This requires some commitments and is a barrier to entry for
- Using service like Github Search or SourceGraph helped a lot in term
of navigating through the commit message / git blame.
- I leverage both Github action and a patch that added Gitlab CI to run
the test suite.
> 3. Do you think patchwork goes in a direction that is likely to help
> with these?
> 4. What other tools would you like to see that could help?
With all that said, I don't know if patchwork will solve the problems
above. I do understand that the current patch workflow comes with a
certain set of advantages, and adopting another tool will most likely be
Personally I have been spending more and more time reading through
git.git via Sourcegraph Web UI and I would love for the search feature
to be able to extend to be able to search in the Mailing List from
relevant commit if possible. I have also tried both Github's Codespace
and Microsoft's DevContainer to setup an opionated IDE with predefined
tasks that help executing the test suite. I think these tools (or
their competitors such as GitPod) are quite ideal to quickly onboard
new contributors onto a history-rich codebase such as git.git.
Perhaps some configure a set of sane default, including editor extensions
that would handle email config for first time users.
As for code review and issue tracking toolings, I don't think there are
a perfect solution. Any solutions: Github PR, Gitlab MR, Gerrit,
Phabricator would come with their own set of tradeoffs. I like the
prospect of PatchWork gona improve the patch workflow though. Perhaps I
will give it a try.
More information about the Patchwork