Home | About | Sematext search-lucene.com search-hadoop.com
 Search Hadoop and all its subprojects:

Switch to Threaded View
Accumulo >> mail # dev >> GIT


On Wed, Jun 5, 2013 at 9:16 AM, Josh Elser <[EMAIL PROTECTED]> wrote:

>
>
> On 6/5/13 8:44 AM, Keith Turner wrote:
>
>> On Tue, Jun 4, 2013 at 10:49 PM, Josh Elser <[EMAIL PROTECTED]> wrote:
>>
>>
>>> On 06/04/2013 10:26 PM, Benson Margulies wrote:
>>>
>>>  1.4.4 has been released. The first person finds some changes that should
>>>>
>>>>> be
>>>>> placed into a 1.4.5 release. As such, a 1.4.5-SNAPSHOT branch would be
>>>>> created from the 1.4.4 tag.
>>>>>
>>>>>  What's the advantage of 1.4.5-SNAPSHOT as opposed to a branch named
>>>> 1.4.x? On other projects, there's an assumption of one branch per
>>>> maintained minor version, with point releases as tags along they way.
>>>> How is your more complex? scheme advantageous?
>>>>
>>>>  Much of this discussion is entirely based on the fact that my opinions
>>> were solicited while the majority of people tended not to agree with how
>>> I
>>> would prefer to manage branches.
>>>
>>> As such, I've stopped arguing my points as, and will attempt to be
>>> detached.  Having been part of transition a decent-sized "subversion"
>>> team
>>> to git, which typically tries to manage with 2+ concurrent releases, I've
>>> developed my own opinions on how to manage this. Most of it stems from
>>> lack
>>> of moderation on where changes should be made in such an environment and
>>> that history is easily mucked up and when changes are placed in
>>> inappropriate places. If it seems completely absurd to even have this
>>> discussion (I don't fault you in the slightest -- I'm 99% there myself),
>>> I'm actively working a write-up to track concrete decisions.
>>>
>>>
>> Can you give more detail about "history is easily mucked up"?  I am
>> curious
>> what constitutes a mucked up history and what sequence of steps lead to
>> this?
>>
>>  http://dan.bravender.us/2011/**10/20/Why_cherry-picking_**
> should_not_be_part_of_a_**normal_git_workflow.html<http://dan.bravender.us/2011/10/20/Why_cherry-picking_should_not_be_part_of_a_normal_git_workflow.html>

Thanks for the link, I do not think I could have easily found this via
google because I would not have know what to search for.  I have little
experience w/ git outside of small projects on github w/ one branch.  Info
like this helps me make informed decisions.   Cherry picking vs merging
seems to be at the heart of what you are talking about, are there any other
key concepts?

Would probably be good to add this link, plus the other useful links posed
in this thread, to the document you are working on.  I can make that change
if you put it somewhere.
>
>
>>
>>> As far as a minor-release branch name, I really just don't care. It's a
>>> name. My opinion is to tie it to something specific and meaningful. I do
>>> not find 1.4.x nomenclature meaningful, so, as such, I proposed
>>> alternatives.
>>>
>>> Ultimately, I hope that those currently performing the most development
>>> should form their own opinion from the facts that have been presented
>>> when
>>> it comes time for a decision to be made.
>>>
>>>
>>