accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Josh Elser <josh.el...@gmail.com>
Subject Re: [jira] [Commented] (ACCUMULO-1961) Fix trivial compiler/javadoc warnings
Date Fri, 21 Feb 2014 00:27:14 GMT
Mike, fwiw `git config --global --add push.default matching` will do 
exactly as you specified with a simpler command (git push apache)

A value of "current" is a pretty safe bet too that lets you avoid the 
refspec argument and will push the current branch by default.

http://git-scm.com/docs/git-config and search for push.default for a 
nice write-up on the different options.

IMO, you can use Git however the heck you want (TIMTOWDI). But if you 
mess up, I'll call you out on it ;)

On 2/20/14, 4:12 PM, Mike Drob wrote:
> 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
View raw message