[Insight-developers] Failed to merge a gerrit patch

Bill Lorensen bill.lorensen at gmail.com
Mon Aug 15 11:16:37 EDT 2011


Many of us merge another person's topic. Sometimes for someone without
permission but mostly to get it there since it has been approved. It is more
efficient.

I realize the workflow can change. I just think that this is a step
backwards.

I guess I can always make my own alias to do what I want to do.

Bill

On Mon, Aug 15, 2011 at 11:13 AM, David Cole <david.cole at kitware.com> wrote:

> Perhaps the basic problem here is that you are trying to merge someone
> else's topic. Is this just to "get it in there" or is this usually
> from somebody without write access...?
>
> The author of a commit should be the one to merge it if he has write
> access.
>
> I think the safeguards put in to prevent accidental merges should be
> kept. Even if it forces some of us to change our workflow.
>
> We do not have a backwards compatibility requirement on our
> workflows... We do have a strong obligation to keep unintended changes
> out of the 'master' branch of the main repository.
>
>
>
> On Mon, Aug 15, 2011 at 7:58 AM, Bill Lorensen <bill.lorensen at gmail.com>
> wrote:
> > Matt,
> >
> > I understand your description of how things work.
> >
> > Before your changes to the gerrit aliases I would:
> >
> > 1) git checkout -b topic
> > 2) cherry pick the topic
> > 3) git gerrit-merge
> >
> > This no longer works.
> >
> > I think it's a bug. Try it yourself the next time you want to merge some
> > else's topic (i.e. one that you have never pushed to gerrit).
> >
> > Bill
> >
> > On Sun, Aug 14, 2011 at 10:38 PM, Matthew McCormick (thewtex)
> > <matt at mmmccormick.com> wrote:
> >>
> >> On Sun, Aug 14, 2011 at 5:55 PM, Bill Lorensen <bill.lorensen at gmail.com
> >
> >> wrote:
> >> > I cannot do a push after the cherry pick because gerrit reports that
> >> > nothing
> >> > has changed.
> >>
> >> 'git cherry-pick' says take a commit and merges it into the current
> >> branch.  If the HEAD of the current branch is the same as the parent
> >> of the commit, then nothings changes.  No 'git gerrit-push' is
> >> required.  If, however, master is advanced ahead of parent of the
> >> commit, a merge is required.  There may or may not be merge conflicts.
> >>  The cherry-picked commit has a different parent, and the code that
> >> surrounds it is different.  In this case, a 'git gerrit-push' is
> >> required, as it should be.  It is effectively re-basing on master.
> >>
> >> >
> >> > I can do a commit -amend and add a bogus change to the commit message
> >> > and
> >> > then successfully push.
> >>
> >> This was not necessary in this case.  A direct 'git gerrit-merge'
> >> should have worked.
> >>
> >> > I can live with this, but it is a change from the
> >> > previous work flow. I avoid the checkout line because it often
> rebuilds
> >> > too
> >> > much stuff.
> >>
> >> I think it is good to know when a rebase occurs, and to have builds to
> >> verify that the rebase did not cause problems.  The robots are
> >> computers, not people -- they will not complain to much if they have a
> >> little extra work ;-).
> >>
> >> >
> >> > Actually, I would prefer that the recent commit check be removed. I
> >> > realize
> >> > that it was adeed to prevent a bogur gerrit-merge, but I question how
> >> > often
> >> > that happened.
> >>
> >> I am of the mind "It's a feature, not a bug."
> >>
> >> Matt
> >
> >
> > _______________________________________________
> > Powered by www.kitware.com
> >
> > Visit other Kitware open-source projects at
> > http://www.kitware.com/opensource/opensource.html
> >
> > Kitware offers ITK Training Courses, for more information visit:
> > http://kitware.com/products/protraining.html
> >
> > Please keep messages on-topic and check the ITK FAQ at:
> > http://www.itk.org/Wiki/ITK_FAQ
> >
> > Follow this link to subscribe/unsubscribe:
> > http://www.itk.org/mailman/listinfo/insight-developers
> >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.itk.org/mailman/private/insight-developers/attachments/20110815/9b6a831b/attachment.htm>


More information about the Insight-developers mailing list