On Sun, Mar 10, 2013 at 12:06 AM, Dan Andreescu <dandreescu(a)wikimedia.org>wrote;wrote:
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(a)gmail.com