accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Keith Turner <ke...@deenlo.com>
Subject Re: [jira] [Commented] (ACCUMULO-1961) Fix trivial compiler/javadoc warnings
Date Fri, 21 Feb 2014 00:50:30 GMT
On Thu, Feb 20, 2014 at 7:12 PM, Mike Drob <madrob@cloudera.com> wrote:

> I recommend "git push apache : -n" where 'apache' is the name I have given
>

Will this push the branches in the correct order?


> 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