51–60 of 168 posts
Earlier quoted context omitted.
I've used gerrit and it's much better than github/bitbucket. My knock on gerrit is it requires one "very good" git person to be on the team however it makes it very easy to support a larger team and do cleaner code reviews.
https://xkcd.com/1597/
Exactly how everyone I know uses git.
Mistake #1.
Earlier quoted context omitted.
If you don't understand, then clearly you should investigate why as you cannot form an opinion on something you don't understand.
I have investigated, why are you assuming I have not?
Why are they all rebasing in their PR branches if it obviously makes the PR unreadable?
The idea of a more in-depth review is intriguing (we all know this is something that can be improved), but _voting_ on a peer's code just seems like a bad idea. Vote too low, people get insulted and you breed discontent and mistrust. Too high and everyone stays happy until code quality drops. People will either use this as an opportunity to diminish other's, show off or suck up. Sad, but that's human nature.
I know in-person code reviews aren't always possible but adding this disconnect just seems like a bad idea. Would love some honest feedback from people who have actually used it in medium-large scale production.
Earlier quoted context omitted.
I've never understood why people think omitting a historical event keeps their "history clean".
Because I've yet to find a git graphlog tool which made viewing pretty nonlinear git history (as precise a historical record as they are) anything but a pain in the ass, some of them barely even manage to display a dozen concurrent "branches". This is combined with most of the "historical record" really being worthless garbage: does it matter that you had to implement 12 fixups at various points and rewrite the whole…
One of the largest problems I've had getting gerrit adoption on smaller teams is that they can just pop up a private github team easily, whereas finding hosted gerrit solutions that actually make it easy to convert from other source control tooling has been very difficult.
The process might seem more complex initially but think of it like this: If you add a new member to your team, they would have to fork the repositories on GitHub, clone them locally, make the changes, push to their own fork and then create the pull request Annndddd we're done - its easy to make a pull request from a branch; this person has no idea what they're doing. In addition, the new GitHub code review tools addr…
I had the same impression reading the intro; I was done after reading about Agile and consultants. In every single instance I've seen these two combined, mediocrity followed. Even in the cases where they thought they had agility the results were still terrible and unproductive. Most of the time its people not understanding the tech they're trying to use and instead of spending the time to learn it they look for somet…
The process might seem more complex initially but think of it like this: If you add a new member to your team, they would have to fork the repositories on GitHub, clone them locally, make the changes, push to their own fork and then create the pull request Annndddd we're done - its easy to make a pull request from a branch; this person has no idea what they're doing. In addition, the new GitHub code review tools addr…