Return-Path: X-Original-To: apmail-accumulo-dev-archive@www.apache.org Delivered-To: apmail-accumulo-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 48D4311417 for ; Fri, 21 Feb 2014 00:12:49 +0000 (UTC) Received: (qmail 86744 invoked by uid 500); 21 Feb 2014 00:12:48 -0000 Delivered-To: apmail-accumulo-dev-archive@accumulo.apache.org Received: (qmail 86700 invoked by uid 500); 21 Feb 2014 00:12:48 -0000 Mailing-List: contact dev-help@accumulo.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@accumulo.apache.org Delivered-To: mailing list dev@accumulo.apache.org Received: (qmail 86692 invoked by uid 99); 21 Feb 2014 00:12:48 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 21 Feb 2014 00:12:48 +0000 X-ASF-Spam-Status: No, hits=1.5 required=5.0 tests=HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of mdrob@cloudera.com designates 209.85.219.42 as permitted sender) Received: from [209.85.219.42] (HELO mail-oa0-f42.google.com) (209.85.219.42) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 21 Feb 2014 00:12:44 +0000 Received: by mail-oa0-f42.google.com with SMTP id j17so910586oag.29 for ; Thu, 20 Feb 2014 16:12:21 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:content-type; bh=kQkP8kkrEZeL8rnq0PkDvjIqng+6SyVbJ0qbHnvYxrM=; b=WHy+8K9IIP3x/WJnljK52WVr8qRTkjKQSWAA9Vj/1cHLNd/yyaHCS+FLxw5vQdxfWJ ZGKZInXt7okZqf5or0PotoyWyNmAS4E4WOa2nCG7gmFSL3gD5ZhoIL6+m5jD/9G9KxRk csn5rZwavrWqmm15S6vIHUvLgjKaaowPfDgRcPci48D821Nr4WFU3RxkUvRShmFPtD+j ReMBK8iDHu7j/0q1aiqefy9mWxC8+TdTHNZZeaUYhuguxzeiPkQ/sHPenzUBXdstQWVy kRh4L6N5XB7U2JPv5HSv0ZnyAm76BM+a77uPd3QC8UUl3yGtOCE3uezTj7q+FANuJ9p+ O8ZQ== X-Gm-Message-State: ALoCoQnCyG7ae/NRuaTEw9qPLTKGSvIhYn5Q6SScWFEu9cOR1P/XN55if+2A7uBvdbeStcoIv0WS X-Received: by 10.182.40.37 with SMTP id u5mr1158074obk.41.1392941541779; Thu, 20 Feb 2014 16:12:21 -0800 (PST) MIME-Version: 1.0 Received: by 10.60.95.161 with HTTP; Thu, 20 Feb 2014 16:12:01 -0800 (PST) In-Reply-To: References: From: Mike Drob Date: Thu, 20 Feb 2014 19:12:01 -0500 Message-ID: Subject: Re: [jira] [Commented] (ACCUMULO-1961) Fix trivial compiler/javadoc warnings To: dev@accumulo.apache.org Content-Type: multipart/alternative; boundary=f46d04440140ca7ffb04f2df79d6 X-Virus-Checked: Checked by ClamAV on apache.org --f46d04440140ca7ffb04f2df79d6 Content-Type: text/plain; charset=ISO-8859-1 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 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 wrote: > > On Thu, Feb 20, 2014 at 5:05 PM, Mike Drob 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 > 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 > >> > 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) > >> > >> > 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 > >> > > | - - - > >> > > >> > --f46d04440140ca7ffb04f2df79d6--