Hey,
Is it possible to push to a branch other then the default one on gerrit using git review?
This is needed when you want to have more then one branch on which you have reviewed code, or if you want different levels of review. For example if you want a novice committer play around with an extension a bit and push new functionality that gets reviewed but is not ready to go onto master until it really has stabilized and finalized.
Cheers
-- Jeroen De Dauw http://www.bn2vs.com Don't panic. Don't be evil. --
I too have been wondering how to do this.
My main use cases are 1) when I want to easily share something experimental with others (my current process involves pushing for review and then having to remember to -1 it) 2) when I want to collaborate with someone (without the ability to push to gerrit) on a branch
On Wed, May 23, 2012 at 1:00 PM, Jeroen De Dauw jeroendedauw@gmail.com wrote:
Hey,
Is it possible to push to a branch other then the default one on gerrit using git review?
This is needed when you want to have more then one branch on which you have reviewed code, or if you want different levels of review. For example if you want a novice committer play around with an extension a bit and push new functionality that gets reviewed but is not ready to go onto master until it really has stabilized and finalized.
Cheers
-- Jeroen De Dauw http://www.bn2vs.com Don't panic. Don't be evil. -- _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On Wed, May 23, 2012 at 8:00 AM, Jeroen De Dauw jeroendedauw@gmail.com wrote:
Hey,
Is it possible to push to a branch other then the default one on gerrit using git review?
This is needed when you want to have more then one branch on which you have reviewed code, or if you want different levels of review. For example if you want a novice committer play around with an extension a bit and push new functionality that gets reviewed but is not ready to go onto master until it really has stabilized and finalized.
Yep, totally possible. Just do:
`git push <remote> HEAD:refs/for/<branchname>`
If you want to change the default branch (say for a long-term development branch), you can also change 'defaultbranch' in your .gitreview file.
-Chad
On Wed, May 23, 2012 at 7:06 AM, Antoine Musso hashar+wmf@free.fr wrote:
I think the branch is given as an argument to git-review, aka:
git review [BRANCH]
That's right. You can submit to a different branch by running 'git review branchname'. Also, if you create a branch that's gonna stick around for longer, you can change the .gitreview file in that branch and set defaultbranch to the correct branch name, so git review will automatically pick the right branch. This is what we do with the wmf/* branches.
Roan
Hey,
Thanks all for pointing to the already existing solution :)
One note I'd like to add for people that want to do this: you need to create the branch on gerrit first, else git review will go mad at you.
Cheers
-- Jeroen De Dauw http://www.bn2vs.com Don't panic. Don't be evil. --
How do you create the new branch on gerrit?
Ryan Kaldari
On 5/29/12 6:22 AM, Jeroen De Dauw wrote:
Hey,
Thanks all for pointing to the already existing solution :)
One note I'd like to add for people that want to do this: you need to create the branch on gerrit first, else git review will go mad at you.
Cheers
-- Jeroen De Dauw http://www.bn2vs.com Don't panic. Don't be evil. -- _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Ryan Kaldari rkaldari@wikimedia.org wrote:
How do you create the new branch on gerrit?
In Gerrit Web UI:
Admin -> Projects -> (choose project) -> Branches -> Create branch
//Saper
Marcin Cieslak schrieb:
Ryan Kaldarirkaldari@wikimedia.org wrote:
How do you create the new branch on gerrit?
In Gerrit Web UI:
Admin -> Projects -> (choose project) -> Branches -> Create branch
I justed wanted to create a new remote branch today to show other my work. With the usual git push -u origin <my-branch>:<new-remote-branch> I just got the described problem that Gerrit rejected the new branch.
So I felt very lucky to see the issue just coming up in this thread and wanted to try your solution. Yet at https://gerrit.wikimedia.org/r/#/admin/projects/mediawiki/core,branches I can't find a button to create a new branch. Will I need additional rights for that?
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?
Bergi
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
Marcin Cieslak schrieb:
Bergia.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?
You are supposed to push one perfect commit for review; you might also push some with dependencies between them but then things get nasty.
Yes, I feared that. Too bad.
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?
Thanks, Bergi
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
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).
wikitech-l@lists.wikimedia.org