On Sun, Mar 10, 2013 at 12:06 AM, Dan Andreescu dandreescu@wikimedia.orgwrote:
I disagree and I have a very simple counter-point. Gerrit makes it basically impossible to work in a git-flow style ( http://nvie.com/posts/a-successful-git-branching-model/
). From what I understand, rebasing and good branching strategies like git-flow simply don't get along.
This is not true. The purpose of git-rebase is very clear and outlined. It's something you use *before* you implement branching strategies. In other words, you're supposed to work on a feature in a branch, and right before you push your branch to a remote, you fetch origin and rebase on master so that all conflicts are resolved. Only then does branching and anything else matter.
Also, in a project like MediaWiki, where numerous individual contributors are submitting patches rather than a small set of trusted employees, a model where the maintainer is responsible for resolving conflicts in merges is simply not feasible.
To be fair, though I understand the arguments against using github (though
accepting pull requests from it is a must!), I always had the impression that other options weren't given enough attention during that discussion. Particularly GitLab looked very usable, could be used for self-hosting, etc., and never even got much content in the "case against" section (only two items, both currently marked as "no longer true"). I am not entirely sure why it was discarded so promptly in favor of the admittedly powerful, but clearly problematic/controversial Gerrit. Are there strong reasons do dismiss it that weren't stated in that page?
What's the difference between GitHub's and GitLab's merge request workflow?
*--* *Tyler Romeo* Stevens Institute of Technology, Class of 2015 Major in Computer Science www.whizkidztech.com | tylerromeo@gmail.com