On 2020-06-21 17:07, Sad Clouds wrote:
On Sun, 21 Jun 2020 10:32:32 -0400 gary%duzan.org@localhost wrote:On 2020-06-21 16:07, Rhialto wrote:On Sun 21 Jun 2020 at 15:20:39 +0200, Johnny Billquist wrote:I am still curious about how to manage well in git the scenario where you do have a central repository that holds the actual source of truth, and where you want to review and approve anything that gets committed.Let me point you to the hell that is called "Gerrit"... Example: https://review.opendev.org/Like I said. We are using gerrit. It's not without a bunch of issues all on its own... :-) Any other options around with similar functionality? JohnnyOur group at work uses Gerrit. We have had some trouble maintaining it, so we have been considering moving to Bitbucket, which already exists in the company. Bitbucket seems nice enough, though of course it is commercial. If I were looking for a solution today I would consider Phabricator/Differential, as it is open source, supports Mercurial, and appears decent enough. Gary DuzanWhat is the actual benefit of these tools? In a commercial environment I find them to be a complete distraction and it often results in people blocking you from committing changes due to various petty reasons. Ideally, you wouldn't need to manage anything, you trust your team members to use their own experience and commit correct and well tested code. You can still review the changes on their private branch, but you can easily do that on the command line - "svn diff --diff-cmd=meld ..." was the best review tool for me.
Not talking about a specific tool, but the process then. There are multiple advantages by having code reviewed.First of all, noone is perfect. People make mistakes all the time, and having two people look at it already reduce silly errors significantly.
Even when you have unit tests (which you should), there are still plenty of errors not caught by that. However, automatically running unit tests on all code to be committed, *before* it is committed, is also very valuable. For which you obviously need a process.
Thirdly, it is also about spreading knowledge. It is never good to have just one person be familiar with some code. By having another person review things, you have at least two people who have a little deeper understanding of the code.
There is absolutely nothing wrong with going back and reviewing already committed code later. But in all honestly, that's more often than not the exception rather than the rule. So I would never count on such a process.
Finally, there are also the larger system type issues to be considered. Code might be perfectly fine in the local context, but others might also know a bit about other modules this code interacts with, and how those other modules work, and how they expect things to be used. And code reviews help catch those kind of issues as well. And it also helps from a system architecture point of view to make sure that the code is designed and works the way the overall design was intended, and that people don't drift off and start doing things in completely different ways which will break the overall design.
When you are in projects with more than a couple of people writing and committing code, all of these issues have always been appearing, in my experience.
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt%softjar.se@localhost || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol