Hi Stefan,
> Franz I think maybe it is a good idea to amend the Developer Guide on
> how to maintain branches.
Very true.
(Only technical nitpicking follows below.)
> 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.
Well, *technically*, Matthias was not too wrong.
If Sabine would have rebased her patch onto the current master, this would have
created just one single new commit.
Pushing that commit to Gerrit would not create more than one change.
The topic you're addressing is a bit different: What happens when that commit
is *submitted*?
Since the submission strategy for the Saros project is "cherry-picking" anyway,
it does not matter where a particular change was based before submission, as
long as there are no merge conflicts.
Example: The initial state (read from left to right in typewriter font), A is
where "development/netbeans" currently stands, B is where "master" is, C is the
current patch set of the change for the netbeans branch.
C
/
*--A--*--*--B
Rebasing C to current master, thus creating new patch set D, branch labels
unchanged at A and B.
C D
/ /
*--A--*--*--B
Submission of D to branch "development/netbeans" (creates new commit D',
advances branch label "development/netbeans" to D').
C
/
| D' D
|/ /
*--A--*--*--B
This submission only works if D is applicable to both B and A (i.e. there is no
merge-conflict).
This shows that rebasing a change under these circumstances does not have any
effect.
The right thing to do would have been to merge the master branch into the
dev-branch first (creating merge-commit E, advancing branch label
"development/netbeans" to E):
C
/
| ---------E
|/ /
*--A--*--*--B
... and then to rebase C onto the E (creating new patch set F):
C F
/ /
| ---------E
|/ /
*--A--*--*--B
The submission of that change would result in the new commit F' (where the
branch label "development/netbeans" is moved to):
C F
/ /
| ---------E--F'
|/ /
*--A--*--*--B
Cheers,
Franz
-----Original Message-----
From: Stefan Rossbach [mailto:srossb...@arcor.de]
Sent: Monday, June 29, 2015 1:20 PM
To: Zieris, Franz
Cc: dpp-devel@lists.sourceforge.net
Subject: Re: [DPP-Devel] Gerrit clean-up
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
