On Sun, Mar 10, 2013 at 12:06 AM, Dan Andreescu <dandree...@wikimedia.org>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 | tylerro...@gmail.com _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
