accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher <ctubb...@apache.org>
Subject Re: [jira] [Commented] (ACCUMULO-1961) Fix trivial compiler/javadoc warnings
Date Fri, 21 Feb 2014 01:40:28 GMT
The man page for git-config says about "push.default = matching": "It
is not appropriate for pushing into a repository shared by multiple
users, since locally stalled branches will attempt a non-fast forward
push if other users updated the branch."

This is actually the default for git versions <2.0, and if I
understand the warning correctly, it will not guarantee avoiding the
race conditions we're trying to avoid by pushing in order, even if it
did push in order (which I can't find any documentation indicating
that it does, or that it is guaranteed to).

--
Christopher L Tubbs II
http://gravatar.com/ctubbsii


On Thu, Feb 20, 2014 at 7:50 PM, Keith Turner <keith@deenlo.com> wrote:
> 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
View raw message