accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mike Drob <mad...@cloudera.com>
Subject Re: [jira] [Commented] (ACCUMULO-1961) Fix trivial compiler/javadoc warnings
Date Fri, 21 Feb 2014 00:12:01 GMT
I recommend "git push apache : -n" where 'apache' is the name I have given
the asf remote and ':' indicates to push matching branches, and -n is dry
run.


On Thu, Feb 20, 2014 at 6:41 PM, Christopher <ctubbsii@apache.org> wrote:

> Definitely avoid git push --all. I don't think the order is well
> defined. But, I do agree that a good workflow is to do all the merges
> in order, then go back and do all the pushes in order.
>
> --
> Christopher L Tubbs II
> http://gravatar.com/ctubbsii
>
>
> On Thu, Feb 20, 2014 at 5:32 PM, Keith Turner <keith@deenlo.com> wrote:
> > On Thu, Feb 20, 2014 at 5:05 PM, Mike Drob <madrob@cloudera.com> wrote:
> >
> >> I think the difference in workflow is that some committers push and
> merge
> >> branches one at a time, while other committers merge everything locally
> and
> >> then push all at once. I strongly prefer the second approach.
> >>
> >
> > The second approach is best.  Still need to be careful.  AFAICT git push
> > -all is not an atomic operation across all branches.  Need to push the
> > oldest branch first.  Will 'git push -all' do this?  If not, then should
> > push branches in correct order.
> >
> >
> >
> >
> >
> >>
> >>
> >> On Thu, Feb 20, 2014 at 4:54 PM, Christopher <ctubbsii@apache.org>
> wrote:
> >>
> >> > I agree you definitely don't want to be skipping specific commits when
> >> > merging... but that's not what Mike nor I suggested. Rather, our
> >> > suggestion was that you can do a regular merge of any parentage,
> >> > before doing a -sours merge of your commit.
> >> >
> >> > To John's point, this is essentially what the previous committer
> >> > should have done (in this case, me) before your commit arrived.
> >> > However, there is a race condition here... and the previous committer
> >> > may be in the process of doing this when you come on the scene. So,
> >> > you should always be extra careful about merging.... especially with
> >> > -sours.
> >> >
> >> > --
> >> > Christopher L Tubbs II
> >> > http://gravatar.com/ctubbsii
> >> >
> >> >
> >> > 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