Have you ever tried the git e-mail workflow? I think you may like it, I'd be curious to have your opinion about how it compares to your workflow above :-).
The idea is that you just send your patch by e-mail, and the reviewer just applies it with `git am <the patch>`. So you don't even have to sync on a branch. Then the reviewer can comment directly on the patch. You answer with new versions of the patch, and get new reviews. It's minimal, actually decentralized (unlike, say, GitHub), and I believe it has the advantages of your workflow above.
I have been giving this one a lot of thought. I jumped to sourcehut for my personal projects and was amazed how viscerally pleasing a [PATCH] email thread could be. I am convinced there is a big psychological difference between discussions via Pull Requests and discussions via email/mailing lists. I can’t pin point it but it is almost palpable.
A question I have with the process is: can email based workflow still work with for a continuous integration/delivery pipeline?
Same :-). I also love how people don't have to create an account to send a patch. They just need to send me an e-mail. That is not a problem on GitHub (because everybody is forced to have an account there), but it is if you want to host your repo somewhere else.
> can email based workflow still work with for a continuous integration/delivery pipeline?
The biggest drawback is the inability to use on a computer without email setup, e.g. not from the main computer, or from mobile devices - smartphone, tablet. In my case it's not uncommon to do a quick review of some PRs using this Web-based workflow. Now with newer GitHub application it's even easier.
You don't send a diff, you send an e-mail formatted by git. So you get all the commits you put in it, it's really just like seeing the commits in a GitHub PR.
So the reviewer receives the commits, with their descriptions, authors, everything. Just like pulling a branch, really.
You do lose the information about where to apply the patch. This isn't a big problem for rebase-friendly crowd. But people who prefer the merge strategy strictly may not like it.
AFAICS there's `--base=auto` which captures explicit parent's sha in the patch text output (there's also a git config option to do that automatically).
Thank you for the information! This is the first time I'm hearing about it. Would you happen to know how this information is used? Is it just for the maintainer, or is there a tool that can use it? (I couldn't find any other reference)
It is really easier than it looks! Took me a while to try it, but then I realized it's really super easy: run the git command to create the e-mail, send the e-mail, and on the reviewer side just run the command to apply it.
This is a nice tutorial, too, but I would recommend reading Drew Devault's posts first (and watching his short videos):
The idea is that you just send your patch by e-mail, and the reviewer just applies it with `git am <the patch>`. So you don't even have to sync on a branch. Then the reviewer can comment directly on the patch. You answer with new versions of the patch, and get new reviews. It's minimal, actually decentralized (unlike, say, GitHub), and I believe it has the advantages of your workflow above.
Nice posts about it:
https://drewdevault.com/2018/07/02/Email-driven-git.html
https://drewdevault.com/2022/07/25/Code-review-with-aerc.htm...