On Thu, Sep 01, 2016 at 01:03:18PM +0530, Kaushal M wrote: > On Thu, Sep 1, 2016 at 12:36 PM, Nigel Babu <nig...@redhat.com> wrote: > > On Mon, Aug 29, 2016 at 10:55 AM, Poornima Gurusiddaiah > > <pguru...@redhat.com> wrote: > >> > >> Hi, > >> > >> Regarding the enforcement of the dependencies while merging, i see that > >> the dependent patches on any patch is mentioned in the "Related Changes" > >> column [1]. It still doesn't enforce, in the cherry-pick way of > >> submitting changes, by default it ignores the lineage [2]. But there are > >> ways to enforce this. Will let the gluster infra maintainers to comment > >> on the same. > >> > >> [1] > >> https://gerrit-review.googlesource.com/Documentation/user-review-ui.html#related-changes > >> [2] > >> https://gerrit-review.googlesource.com/Documentation/project-configuration.html#project_options > >> > >> Regards, > >> Poornima > > > > > > Thank you Poornima for pointing this out. You're right, it's worth changing > > our submission type to either "Rebase If Necessary" or "Merge If Necessary" > > to enforce this. I'm not sure what the implications are, so I'll report back > > after I've setup a test on staging so we can experiment and see what works. > > The reason cherry-pick was chosen was to keep the branch linear and > avoid merge-commits as (I'm guessing here) this makes the tree hard to > follow. > Merge-if-necessary will not keep the branch linear. I'm not sure how > rebase-if-necessary works though. > > Vijay, can you provide anymore background for the choice of > cherry-pick and you opinion on the change? > > >
As the name suggests, Rebase-if-Necessary does what you'd do on the commandline before merging two remote branches linearly. That is, eebase the change just before merging and then do a fast-forward merge. That should, if it works correctly, make the history linear. -- nigelb _______________________________________________ Gluster-devel mailing list Gluster-devel@gluster.org http://www.gluster.org/mailman/listinfo/gluster-devel