Hi, > In general, no. Using a forge introduces numerous opportunities for race > conditions (reviewing a PR and having someone else update it before you > merge it, for instance) and compromises of other systems (the forge shows > you something different than what it would merge when you press the merge > button). It is then possible to configure the forge to eliminate those > again, but it has to be done carefully and nearly all users of forges do > not do so.
If you are concerned about the PR being updated without you noticing it (very unlikely), you can git pull it locally, review locally and git push on mainline, which with all modern Forges will automatically close the PR/MR/issue. Using real git commits with SHA hashes, signatures, SSH key protected pulls and pushes, multiple server logs on who did what etc is easily more secure than using plaintext emails. I am sure anybody reading this can see why if they are honest to themselves and not trying to find straw man arguments to blame. The big question here you seem to avoid commenting on is what is the workflow you expect the next generation to seriously adopt? Any plans to write a new e-mail client and then ask e.g. university students to start learning it? Or will you document your current email setup and start promoting it for new people to embrace instead of using UIs tailored to code reviews?
