On Tue, 05 Jun 2012 01:13:05 -0700, Marcin Cieslak saper@saper.info wrote:
Bergi a.d.bergi@web.de wrote:
Doesn't Git encourage us to create as many branches as we can, to share our work and collaborate? Or should I publish my branch(es) somewhere else, maybe without gerrit at all?
Sorry to say this and many people here might disagree: Forget 80% of git versatility when working with gerrit. No "git merge" (other than fast forward), no "git cherry-pick" (only -n) and branches are rarely useful for more than a local marker for commit. You are supposed to push one perfect commit for review; you might also push some with dependencies between them but then things get nasty. //Saper
On Thu, 07 Jun 2012 01:11:51 -0700, Brion Vibber brion@pobox.com wrote:
On Wed, Jun 6, 2012 at 1:45 AM, Bergi a.d.bergi@web.de wrote:
But I thought there was a possibility to push to our repository without using Gerrit / being affected by Gerrit at all? I can understand that Gerrit is a nice review tool which is useful for the production and master branches, but I'd like to have a repo for developing & sharing cool new features without any review at all. The discussion would happen at bugzilla or mediawiki.org. Do you think there is a way?
Until we get things more nicely sorted out, feel free to maintain development repositories on hosted git services such as:
- github.com
- gitorious.org
- etc
One of the great benefits of git is that you're *not* forced to always use the same server. You can work on code anywhere you like, share it anywhere you like, with anyone you like, and then rebase/flatten and submit up to gerrit when your code is ready.
-- brion
I think I should clear something up / remind people about git.
Firstly, remember there are two types of branches, heck in a way there are three. Branches in your private repo you never push out as actual branches themselves. Branches that you do push out publicly to work on with other people. And branches like our REL#_## branches that are meant to be used by everyone.
Even with whether or not you can push a branch somewhere put aside one thing git is encouraging you to do is create a branch every time you start working on something. Even if you never push it anywhere and you merge it away, squash it, whatever... Git encourages you to branch things so you can easily stop and work on something else in the same project without having to actually destroy what you were working on, deal with explicit `svn commit thisfile, thatfile, andthatfile` and changes being in the same file, having to revert what you were working on just to start something else, or maintain multiple copies of the same repo.
Secondly, Git does NOT encourage you to commit branches into some central repository to share them with other people. ...that's very non-git. Frankly that's very svn. Git encourages you to work with 4 types of copies of the same repo from your viewpoint. - There is a central repository, or maybe multiple of them. eg: Some group of maintainers or maybe something like gerrit is in charge of putting commits into these repos. And everyone pulls final trusted commits from these repos. No unchecked commit goes in here. That includes branches. You never tell a maintainer to put your unfinished half-baked branch into their repo. - Then you have a single private repository on your computer. You pull other peoples commits into this. Work on code. Make commits. And push things elsewhere. - Then you have a single public repository of your own available on the web. Whenever you make changes you want to publish you push them here. If you want something in the central repositories, you push it to your public repo and then you ask a maintainer to pull it, review it, and then push it into the central repo. - Then there are multiple public repos for other contributors to the project. Some on GitHub, some on Gitorious, some on some other host, some on people's own private repos, and maybe the project itself will have some place to host your personal repos. When someone has something you are interested in that has not made it into a central repo yet, you pull it from that person's public repo.
So Git does not encourage you to put half-baked code into any of the maintained repos. Git encourages you to branch your code. Push a collaborative project into your own personal public repo. Talk about it with other people. Have them pull the project from your public repo. When they make an improvement they push it to their public repo. And then you pull what they did into yours and combine it with your improvements. Then when your small group of people are done collaborating on this sub-project one of you make a pull request to one of the maintainers and has them merge it into the central repository.
So Gerrit isn't really directly lacking something here. GitHub, Gitorious, etc... aren't workarounds for collaborating on some sub-project improving MediaWiki. They are actually the git-way of doing this collaboration. The problem with Gerrit here is indirect. It's encouraging people to do away with their own public repository to parade new things around with.
That said. This does make me think that treating branches in my own code-review idea (Gareth) like commits for review. Anyone gets to submit a potential branch for review, just like a commit, and then someone with accept permissions (+2) and permissions in that branch (eg: if rights are restricted for certain patterns) gets to accept that request resulting in the merge/creation of that branch. (or maybe they are actually one and the same thing, commits for review can go into any branch, including ones that don't exist, then when accepted a branch is created). Simply since there is additionally value in some types of sub-projects that everyone is involved in and go through the normal pattern of review (eg: The partial rewrite of a project resulting in 2.0.0).