accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From John Vines <vi...@apache.org>
Subject Re: [jira] [Commented] (ACCUMULO-1961) Fix trivial compiler/javadoc warnings
Date Wed, 19 Feb 2014 21:32:01 GMT
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
> | - - -
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message