On 29.06.2015 09:57, Zieris, Franz wrote:
> Hi Sabine,
>
> probably while attempting to rebase *your patch* on the current master, you
> rebased some 400 commits *from the master branch* to your branch.
>
> Since rebasing creates new commits with new commit-ids, Gerrit simply
> considers these new patches.
> Normally, having the same change-id in the commit message would prevent the
> push command (Gerrit does not accept new patch sets for changes that are
> already merged).
> But since you pushed these new commits with old change-ids to a different
> branch ("development/netbeans"), Gerrit considered to be "cherry-picked" -- a
> reasonable strategy, if you cherry-pick single commits from a feature branch
> onto the master branch, but certainly not in this scenario.
>
> There are a couple of problems here:
> 1. Each new commit created a new change in Gerrit. You'll have to abandon
> them. See the documentation for command line access via SSH [1].
> 2. Each new Gerrit change triggers a Jenkins job. I figure Stefan already
> prepared the Jenkins shutdown, i.e. it does not start any new jobs.
> (@Stefan: Thank you!)
> When you're done with 1., you should kindly ask him to restart Jenkins.
> 3. You should really try to understand what went wrong here on the
> Git/Gerrit level. Admittedly, Git is not too easy to understand.
> But it's kind of the backbone of our development infrastructure and we
> expect everyone to educated oneself to get along with it.
> 4. I'm not sure whether Gerrit offers any configuration options to preclude
> such misuse (even if unintentional).
> So the safest thing for now would be *not* to use a development branch
> but push your changes to the master instead.
>
Franz I think maybe it is a good idea to amend the Developer Guide on
how to maintain branches. Seems she did only that what Matthias has
asked her.
"I would give a +1 if you rebase this. 440 missing patches in your
branch and counting ;)"
Unfortunately Matthias this isn't the way it works with branches. You do
not "rebase" your branches. You have to merge them, i.e merging all new
commits
to the developing branch. Your comment was just plainly wrong. It does
not even matter if the branch is XYZ behind the master as long as there
are not any changes to files that
are already altered in the master.
> @Everyone else: You can use Gerrit as usual, but until the Jenkins server is
> restarted (see step 2), no builds will be made.
> (If you upload new patch sets or new changes before Jenkins is restarted,
> their builds will need to be triggered manually when Jenkins is running
> again.)
>
>
> Franz
>
>
> [1] http://saros-build.imp.fu-berlin.de/gerrit/Documentation/cmd-review.html
>
>
> ------------------------------------------------------------------------------
> Monitor 25 network devices or servers for free with OpManager!
> OpManager is web-based network management software that monitors
> network devices and physical & virtual servers, alerts via email & sms
> for fault. Monitor 25 devices for free with no restriction. Download now
> http://ad.doubleclick.net/ddm/clk/292181274;119417398;o
> _______________________________________________
> DPP-Devel mailing list
> DPP-Devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/dpp-devel
------------------------------------------------------------------------------
Monitor 25 network devices or servers for free with OpManager!
OpManager is web-based network management software that monitors
network devices and physical & virtual servers, alerts via email & sms
for fault. Monitor 25 devices for free with no restriction. Download now
http://ad.doubleclick.net/ddm/clk/292181274;119417398;o
_______________________________________________
DPP-Devel mailing list
DPP-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dpp-devel
