Mailing-List: contact dev-help@accumulo.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@accumulo.apache.org
MIME-Version: 1.0
Reply-To: vines@apache.org
In-Reply-To: 
 <CAD-fFU+ejg4bwg2FQJJxBycQhv4SiRKjiKp00w4vXg2QAHUv8w@mail.gmail.com>
References: <JIRA.12682501.1386101286231@arcas>
 <JIRA.12682501.1386101286231.66426.1392838582147@arcas>
 <CAD-fFUJqRTj1uaCU5a8+WGp4v3WKLRA8N_9VVxKgFiWv6rOmgA@mail.gmail.com>
 <CAL5zq9ZJ7v5_ifUmRbTCnau2wHnotiHVRsVXUxeWYr0H9CojVA@mail.gmail.com>
 <CAD-fFU+ejg4bwg2FQJJxBycQhv4SiRKjiKp00w4vXg2QAHUv8w@mail.gmail.com>
From: John Vines <vines@apache.org>
Date: Wed, 19 Feb 2014 16:32:01 -0500
Message-ID: 
 <CADczPYSFethw9u-wc-2cVteoLoMVoqiC==v+dsq580wR2p7Y0g@mail.gmail.com>
Subject: Re: [jira] [Commented] (ACCUMULO-1961) Fix trivial compiler/javadoc
 warnings
To: Accumulo Dev List <dev@accumulo.apache.org>
Content-Type: multipart/alternative; boundary=089e0160b618e76af204f2c920fc

--089e0160b618e76af204f2c920fc
Content-Type: text/plain; charset=ISO-8859-1

The person who commits to an earlier branch should be merging it forward.
So you really shouldn't have to be orchestrating in the first place. You
put in a commit that doesn't need to be merged forward? Then you do the
empty merge forward.


On Wed, Feb 19, 2014 at 4:21 PM, Bill Havanki <bhavanki@clouderagovt.com>wrote:

> John's strategy can certainly work [1]. I don't think it's a good idea to
> make it a typical part of workflow, though. It's complicated, and I don't
> want to have to look back through the history before each merge (3 of them
> for a 1.4 change) for commits to skip.
>
> Also, skipped commits are still left behind, unmergeable, requiring a
> cherry-pick to be rescued later. So, to be safe, you'd have to wait to find
> out what to do with them before skipping.
>
> I don't know a better tactic, but I have the feeling it must involve less
> branches or less merging.
>
> [1]
>
> http://stackoverflow.com/questions/727994/git-skipping-specific-commits-when-merging
>
>
> On Wed, Feb 19, 2014 at 3:20 PM, Christopher <ctubbsii@apache.org> wrote:
>
> > As Mike pointed out, you can't do it if there is unmerged parents. You
> > have to merge the parents first, then your commit. If there's any
> > commits which are children of the commit you want to merge with
> > -sours, you can single out your specific commit by referencing the
> > sha1 in the merge instead of the branch name. That will leave the
> > children unmerged, still, but will isolate your -sours to just that
> > commit. Then you can merge the remaining children in a separate merge.
> >
> > --
> > Christopher L Tubbs II
> > http://gravatar.com/ctubbsii
> >
> >
> > On Wed, Feb 19, 2014 at 3:03 PM, Bill Havanki <bhavanki@clouderagovt.com
> >
> > wrote:
> > > Popping this out of JIRA since I am changing the subject somewhat.
> > >
> > > Christopher (or anyone, really): Can you give me an example of doing a
> > > merge with -sours but only with specific commits, as recommended? It
> > makes
> > > sense that this is safer vs. sweeping in HEAD. Just trying to refine my
> > > workflow. Thanks!
> > >
> > > Bill
> > >
> > > ---------- Forwarded message ----------
> > > From: Christopher Tubbs (JIRA) <jira@apache.org>
> > > Date: Wed, Feb 19, 2014 at 2:36 PM
> > > Subject: [jira] [Commented] (ACCUMULO-1961) Fix trivial
> compiler/javadoc
> > > warnings
> > > To: notifications@accumulo.apache.org
> > >
> > >     [
> > >
> >
> https://issues.apache.org/jira/browse/ACCUMULO-1961?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13905940#comment-13905940
> > ]
> > >
> > > Christopher Tubbs commented on ACCUMULO-1961:
> > > ---------------------------------------------
> > >
> > > It looks like you are right. Be careful about -sours. You should
> probably
> > > only use that with specific commits, not the HEAD of the branch, which
> > > could reference multiple commits.
> > >
> > > Don't worry about fixing it. I'll redo. There's some other javadoc
> > > errors/warnings and other trivial warnings in master that need to be
> > fixed
> > > anyway.
> >
>
>
>
> --
> | - - -
> | Bill Havanki
> | Solutions Architect, Cloudera Government Solutions
> | - - -
>

--089e0160b618e76af204f2c920fc--