Hi Mateusz, First thing: I'm absolutely no Git nor Gerrit expert, they might correct me when I'm wrong.
> For example, let's assume we start working on the contribution as follows: > 1. Import current sources of our plugin into wip/boostbuildprojectmanager To submit this first commit, it would be best all current developers give a +1 review to show their acceptance that the code is merged to the Qt repositories. Afterwards, you can pull this branch and start further work. > 2. git push gerrit HEAD:refs/wip/boostbuildprojectmanager (?) This would be done after you changed a bit, i.e. created a patch. Imho the command would be something like: git push gerrit HEAD:refs/for/wip/boostbuildprojectmanager > 3. Developers A and B pull the changes Yes, they do to test the new things out. Then they suggest improvements to the patch, and the original developer A or any other pushes a new change set (with step 2). It is important to keep the Change-Id line in the commit footer, so Gerrit knows the new push belongs to an existing change. Once this change is ready for submission (approved), it is cherry-picked to the wip/boostbuildprojectmanager branch and can be pulled by anyone. Further development / coding style corrections go on with new Change sets. Maybe it's best to have a look around at the open changes on Gerrit and how other developers interact with each other. And if you have other questions, feel free to ask :) Best regards, André Am 15.04.2015 um 00:13 schrieb Mateusz Loskot: > On 19 February 2015 at 09:35, Mateusz Loskot <mate...@loskot.net> wrote: >> I've opened GitHub issue [2] devoted to discussion it further >> and prepare the submission through Gerrit. > > Finally, we've decided to work in Gerrit from the start [0], in a new > long-living branch (we've got wip/boostbuildprojectmanager there). > > I've configured my local clones for Gerrit set up according to [1] > and I've familiarised myself with [2] and [3]. > > Now, I've got some Gerrit workflow issues I'd like to clarify. > I'm not the only contributor who is going to work on the contribution > and there will be numerous iterations of update of our Change in Gerrit. > The intro [2] says "Each time a Change is updated, it gains a new Patch Set", > where a new Patch Set contains commits (initial or updated) ready for review. > There is no way to push updates without creating new Patch sets. > > How to arrange iterative intermediate updates, before requesting review? > > For example, let's assume we start working on the contribution as follows: > 1. Import current sources of our plugin into wip/boostbuildprojectmanager > 2. git push gerrit HEAD:refs/wip/boostbuildprojectmanager (?) > 3. Developers A and B pull the changes > 4. Developer A commits some coding style corrections > 4.1 git push gerrit HEAD:refs/wip/boostbuildprojectmanager (?) > ...nothing ready for review yet... > 5. Developer B updates his clone, then commits some more style corrections > 5.1 git push gerrit HEAD:refs/wip/boostbuildprojectmanager (?) > ... step 4 and 5 repeat and interleave... > 6. wip/boostbuildprojectmanager builds, runs and is ready for first review > > Wouldn't the steps in 4. and 5. create noise numerous half-ready Patch Sets? > In order to avoid that, shall we move the early collaboration to > 'private' clone, e.g. on GitHub > and once the contribution is ready for first review, push to Gerrit? > Then, if more updates are requested, prepare them on GitHub, once > ready, push to Gerrit > (as new Patch Set)? > > The [3] says: "Note that pushing to your private clone does not count > as publishing and > is a perfectly valid way to solicit an early review", so I guess that > use of GitHub for > intermediate changes is the way to go, isn't it? > > [0] http://lists.qt-project.org/pipermail/qt-creator/2015-April/004580.html > [1] https://wiki.qt.io/Setting_up_Gerrit > [2] https://wiki.qt.io/Gerrit_Introduction > [3] https://wiki.qt.io/Commit_Policy > > Best regards, > -- Best regards / Mit freundlichen Grüßen André Hartmann, Dipl.-Ing. (FH) Software Project Manager iseg Spezialelektronik GmbH | phone: ++49 (0)351 26996-43 Bautzner Landstr. 23 | fax: ++49 (0)351 26996-21 D-01454 Radeberg / Rossendorf | web: www.iseg-hv.com Geschäftsführer / Managing director: Dr. F. Gleisberg, Dr. J. Pöthig Amtsgericht / Lower district court: Dresden HRB 16250 Ust.-Id.-Nr. / VAT-ID: DE812508942 Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte Informationen. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtümlich erhalten haben, informieren Sie bitte sofort den Absender und vernichten Sie diese Mail. Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser Mail ist nicht gestattet. This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and delete this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. _______________________________________________ Qt-creator mailing list Qt-creator@qt-project.org http://lists.qt-project.org/mailman/listinfo/qt-creator