On 12/17/2009 03:26 AM, Raymond Mancy wrote:
----- "Bill Peck"<bpeck(a)redhat.com> wrote:
> From: "Bill Peck"<bpeck(a)redhat.com>
> To: "Raymond Mancy"<rmancy(a)redhat.com>
> Cc: "List for the development of the Beaker
project"<beaker-devel(a)lists.fedorahosted.org>, "Marian Csontos"
> <mcsontos(a)redhat.com>
> Sent: Thursday, December 17, 2009 7:43:15 AM GMT +10:00 Brisbane
> Subject: Re: git branches and master
>
> On 12/15/2009 07:15 AM, Raymond Mancy wrote:
>
>> ----- "Bill Peck"<bpeck(a)redhat.com> wrote:
>>
>>
>>
>>> From: "Bill Peck"<bpeck(a)redhat.com>
>>> To: "List for the development of the Beaker
>>>
> project"<beaker-devel(a)lists.fedorahosted.org>, "Raymond Mancy"
>
>>> <rmancy(a)redhat.com>, "Marian
Csontos"<mcsontos(a)redhat.com>
>>> Sent: Tuesday, December 15, 2009 1:16:48 AM GMT +10:00 Brisbane
>>> Subject: git branches and master
>>>
>>> Hi Raymond,
>>>
>>> I'm thinking its time to bite the bullet and fix the git repo.
>>>
> Right
>
>>> now we have release-0.4 branch where we have been putting fixes
>>>
> and
>
>>> some
>>> new development that you have been working on like new search.
>>>
> Then
>
>>> we
>>> have master where Marian and I have been working on the scheduler
>>> version. This is painful because we have to commit fixes to both
>>> release-0.4 and to master. Its all my fault for not understanding
>>>
> git
>
>>> and how branches work in it. (hint - they actually work unlike
>>>
> cvs!).
>
>>> So I'd like to make master the main branch and move all
>>>
> development
>
>>> into
>>> branches. This way we can always commit bug fixes to master and
>>>
> push
>
>>> a
>>> new release out when needed but continue to develop in branches
>>>
> and
>
>>> when
>>> done merge into master.
>>>
>>>
>> Sure. This makes sense. Once you have merged release-0.4 into master
>>
> I'll
>
>> create all new devel branches to track master.
>>
>>
>>
>>
>>> I'm willing to merge release-0.4 into master, I'll disable all the
>>>
> 0.5
>
>>> schema changes by commenting them out. Then I'll branch a
>>>
> scheduler
>
>>> version from that which will cleanly merge back in later.
>>>
>>> Does this sound reasonable?
>>>
>>>
>> Yep.
>>
>>
>>
>>
>>> Will you be able to bring your new search
>>>
>>> and column view code to master? I'd like them to be a branch off
>>>
> of
>
>>> master so that we can then merge them in when we are done testing.
>>>
>>>
>>>
>> They're currently sitting in their own branch, so once the testing
>>
> is done it should
>
>> be able to be merged easily enough with master.
>>
>>
>>
>>> If we get this straightened out then it will be much easier to
>>>
> develop
>
>>> and fix bugs.
>>>
>>>
>> Raymond
>>
>>
> Ok.. I've merged release-0.4 into master. I need to sort out the
> table
> changes. I'll hopefully post a script Tomorrow to put your local
> sqllite db back in order.
>
> Next step is to "turn off" the scheduler stuff and branch that.
>
Great. I've merged master into ticket543788, so it should be trivial to put it back
into master after testing.
Hello Again,
I have made the final changes to master (I removed all Scheduler related
code) and committed it. Then I created a Scheduler branch and re-added
everything there. So Marian please work out of Scheduler branch now.
All development branches should be off of master.
All bug fixes should be done in a separate branch as well, unless it
really is only one or two lines.
Examples...
% git checkout master
% git branch bz1223
% git checkout bz1223
make changes..
% git add -u
% git commit -m 'fixes bz1223'
test changes...
tests confirm things work.. commit to master
% git checkout master
% git pull . bz1223
# Fixes are now in master...
% git branch new_feature
% git checkout new_feature
New feature is going to take a while to finish...
Fixes have been made in master...
% git pull . master
continue developing..
% git add -u
% git commit -m 'done with new_feature'
test changes...
tests confirm things work.. commit to master
% git checkout master
% git pull . new_feature
Everybody on the same page? :-)