On Wed, Dec 6, 2017 at 9:16 AM, Tim Armstrong <tarmstr...@cloudera.com>
wrote:

> I wonder if the "Rebase always" merge strategy would help with this
> scenario:
> https://gerrit-review.googlesource.com/Documentation/project-
> configuration.html#submit_type
>
>
"Rebase Always" seems like it would fix the above scenario. If the child
isn't merged, it wouldn't merge both the patches and it would fall back to
the client having to manually merge both the patches.

I recall doing a similar thing quite a while back (i.e. GVO-ing 2 patches
in one go), and the behavior was similar to "Rebase Always", so I had to
manually merge the patches after the GVO succeeded, which seems reasonable
as long as the GVO passes. Not sure if our gerrit settings changed at some
point.


> On Wed, Dec 6, 2017 at 9:04 AM, Daniel Hecht <dhe...@cloudera.com> wrote:
>
> > Sailesh, please keep that in mind with the ServicePool change -- you'll
> > need to explicitly merge part 1 first.
> >
>

Yes, I'll make sure to do that. Thanks.


> > On Wed, Dec 6, 2017 at 8:41 AM, Tim Armstrong <tarmstr...@cloudera.com>
> > wrote:
> >
> > > I think that's a consequence of the "cherry pick" merge strategy. It
> does
> > > seem like a flaw in our merge process. It would be nice if we could
> > > configure gerrit so that it didn't merge patches where the parent
> isn't a
> > > commit on the master branch.
> > >
> > > On Tue, Dec 5, 2017 at 9:31 PM, Sailesh Mukil <sail...@cloudera.com>
> > > wrote:
> > >
> > > > Sorry about that. I thought they would both be merged together, but
> it
> > > > looks like that wasn't the case.
> > > >
> > > > On Tue, Dec 5, 2017 at 6:22 PM, Michael Ho <k...@cloudera.com>
> wrote:
> > > >
> > > > > Thanks Tim for fixing it and Jin Chul for investigating the
> problem.
> > > > Sorry
> > > > > for missing that during code review.
> > > > >
> > > > > On Tue, Dec 5, 2017 at 6:00 PM, Tim Armstrong <
> > tarmstr...@cloudera.com
> > > >
> > > > > wrote:
> > > > >
> > > > > > Thanks for investigating Jin Chul. I came to the same conclusion
> > and
> > > > > merged
> > > > > > the change.
> > > > > >
> > > > > > On Tue, Dec 5, 2017 at 5:57 PM, Jin Chul Kim <jinc...@gmail.com>
> > > > wrote:
> > > > > >
> > > > > > > Hi,
> > > > > > >
> > > > > > > Currently Impala build is broken because the child change was
> > > merged
> > > > > > > without the merge of the parent change.
> > > > > > >
> > > > > > > (parent) https://gerrit.cloudera.org/#/c/8760/: [security]
> Make
> > > the
> > > > > > > kerberos principal configurable for Kudu servers
> > > > > > >
> > > > > > > (child) https://gerrit.cloudera.org/#/c/8761/: IMPALA-6256:
> > > > Incorrect
> > > > > > > principal will be used for internal connections if
> > > FLAGS_be_principal
> > > > > is
> > > > > > > set
> > > > > > >
> > > > > > > A workaround: cherry-pick the parent change.
> > > > > > >
> > > > > > > Best regards,
> > > > > > > Jinchul
> > > > > > >
> > > > > >
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Thanks,
> > > > > Michael
> > > > >
> > > >
> > >
> >
>

Reply via email to