Use case I don't know how to address

Use case I don't know how to address

[Alan Chandler]

I have a use case that I don't know how to address.  I have a feeling 
that the way I propose is not using git to its best advantage, and am 
therefore asking for advice.

As an intermittent software developer I have been using git for a long 
time to track software (GPL licenced) I have developed for a web site 
that I operate supporting a fan club. [Ajax based Chat, a real time Air 
Hockey Game with associated club Ladder, and an American Football 
Results Picking Competition]

Each application uses a pattern like that shown below

Basically I have two branches that interact as follows

        2' - 2a - 3' - 4'  SITE
       /         /    /
1 -  2  ------ 3  - 4  MASTER

I develop and test Locally on the master branch, in the commit 2a I 
update settings (such as database password etc that I need for the 
site), and then progressively merge commits made on master when I am 
happy that they work in the test environment.  A git hook rsyncs the 
site branch to site on each merge or commit on that branch.

The master branch is also pushed to my public git repository (which is 
why passwords are changed on the site branch.  The change made back in 
2a is "remembered" by git, so provided I don't go editing the password 
on the master branch things work fine.

My applications tend to be "skinned" (if that is the right word for the 
html page that forms the backdrop for them) with the fan club web site 
look and feel.  However, I am now trying to make a demo site on my home 
server for these applications, and as such I would like to remove the 
fan club skinning and add my own look and feel.  In fact there are other 
changes necessary, because many of the applications use the associated 
fan club membership information of the user to display - so generically, 
I need to make quite a lot of modifications to make it all work and 
would end up with 4 branches as shown, with the difference in commits 
between 4 and 5 as that major work to update the application.


        2' - 2a - 3' - 4'  SITE
       /         /    /
1 -  2  ------ 3  - 4  TEST
                      \
                        5  ------ 6  MASTER
                         \         \
                           5' - 5a- 6' DEMO


As you can see, in the process I have renamed Master to Test - the 
transition to 5a adds passwords to access the database on my demo site.

The problem comes when I want to now merge back further work that I did 
on the master branch (the 5-6 transition) to the fan club site


        2' - 2a - 3' - 4' ----------------- 6' SITE
       /         /    /                    /
1 -  2  ------ 3  - 4  ------------6'''- 6a TEST
                      \            /
                        5  ------ 6  MASTER
                         \         \
                           5''- 5a- 6'' DEMO


What will happen is the changes made in 4->5 will get applied to the 
(now) Test branch as part of the 6->6'' merge, and I will be left having 
to add a new commit, 6a, to undo them all again.  Given this is likely 
to be quite a substantial change I want to try and avoid it if possible.

Is there any way I could use git to remember the 4->5 transition, 
reverse it and apply it back to the Test branch before hand.


-- 
Alan Chandler
http://www.chandlerfamily.org.uk

Re: Use case I don't know how to address

[Johannes Sixt]

On Samstag, 5. September 2009, Alan Chandler wrote:
> The problem comes when I want to now merge back further work that I did
> on the master branch (the 5-6 transition) to the fan club site
>
>
>         2' - 2a - 3' - 4' ----------------- 6' SITE
>        /         /    /                    /
> 1 -  2  ------ 3  - 4  ------------6'''- 6a TEST
>                       \            /
>                         5  ------ 6  MASTER
>                          \         \
>                            5''- 5a- 6'' DEMO
>
>
> What will happen is the changes made in 4->5 will get applied to the
> (now) Test branch as part of the 6->6'' merge, and I will be left having
> to add a new commit, 6a, to undo them all again.  Given this is likely
> to be quite a substantial change I want to try and avoid it if possible.
>
> Is there any way I could use git to remember the 4->5 transition,
> reverse it and apply it back to the Test branch before hand.

Basically, your mistake was to rename master to test and continue development 
on the demo branch. So what you should do instead is this:

        2' - 2a - 3' - 4' ------ 6' SITE
       /         /    /         /
1 -  2  ------ 3  - 4  ------- 6  MASTER
                      \         \
                        5 - 5a - 6'' DEMO

IOW, you keep developing on master, and merge that into the two deployment 
branches.

In practice, it may be easier to develop commit 6 on DEMO (because you can 
debug it more easily, or for similar reasons), but then you should rebase it 
back to MASTER, reset DEMO back to 5a, and finally merge MASTER into DEMO.

-- Hannes

Re: Use case I don't know how to address

[Alan Chandler]

Johannes Sixt wrote:
> On Samstag, 5. September 2009, Alan Chandler wrote:
>> The problem comes when I want to now merge back further work that I did
>> on the master branch (the 5-6 transition) to the fan club site
>>
>>
>>         2' - 2a - 3' - 4' ----------------- 6' SITE
>>        /         /    /                    /
>> 1 -  2  ------ 3  - 4  ------------6'''- 6a TEST
>>                       \            /
>>                         5  ------ 6  MASTER
>>                          \         \
>>                            5''- 5a- 6'' DEMO
>>
>>
>> What will happen is the changes made in 4->5 will get applied to the
>> (now) Test branch as part of the 6->6'' merge, and I will be left having
>> to add a new commit, 6a, to undo them all again.  Given this is likely
>> to be quite a substantial change I want to try and avoid it if possible.
>>
>> Is there any way I could use git to remember the 4->5 transition,
>> reverse it and apply it back to the Test branch before hand.
> 
> Basically, your mistake was to rename master to test and continue development 
> on the demo branch. So what you should do instead is this:
> 
>         2' - 2a - 3' - 4' ------ 6' SITE
>        /         /    /         /
> 1 -  2  ------ 3  - 4  ------- 6  MASTER
>                       \         \
>                         5 - 5a - 6'' DEMO
> 


I understand what you are saying.  I think I need to consider a slight 
change to it however.  Master is currently the branch that I push to my 
public repository and that should ideally have my NON FAN CLUB skinning

So actually I think I am like this

          2' - 2a - 3' - 4' ------ 6' SITE
         /         /    /         /
  1 -  2  ------ 3  - 4  ------- 6  MASTER
                        \         \
                          5 - -- - 6'' PUBLIC REPO
                           \        \
                            5'''-5a -6''' DEMO






-- 
Alan Chandler
http://www.chandlerfamily.org.uk

Re: Use case I don't know how to address

[Junio C Hamano]

Alan Chandler <alan@chandlerfamily.org.uk> writes:

>        2' - 2a - 3' - 4' ----------------- 6' SITE
>       /         /    /                    /
> 1 -  2  ------ 3  - 4  ------------6'''- 6a TEST
>                      \            /
>                        5  ------ 6  MASTER
>                         \         \
>                           5''- 5a- 6'' DEMO
>
>
> What will happen is the changes made in 4->5 will get applied to the
> (now) Test branch as part of the 6->6'' merge, and I will be left
> having to add a new commit, 6a, to undo them all again.  Given this is
> likely to be quite a substantial change I want to try and avoid it if
> possible.

I presume 6'''-6a has the revert of 4-5?  If so, the next merge should
work just fine.

You have arranged TEST->SITE transition correctly to limiting the SITE
customization to 2a and never merging SITE back to TEST, so we can ignore
SITE branch altogether from now on.  Similarly we can ignore DEMO branch,
since its customization is limited to 5a and it never gets merged back to
MASTER.

    1 -  2  ------ 3  - 4  ------------6'''- 6a-----7a??? TEST
                         \            /            /    
                           5  ------ 6------------7 MASTER

Now, 6-7 is a new feature built on MASTER.  What would happen when it is
merged to TEST to produce 7a?

The merge base for this merge is 6, and since that commit to the tip of
the TEST branch 6a, there is a "skin from vanilla to FanClub" change and
nothing else.  On the other hand, since the merge base to the tip of the
MASTER branch 7, there is a "feature enhancement" but no skin related
changes.

So bog-standard three-way merge should say:

 - One branch, MASTER, added these features, but TEST branch did not do
   anything with these feature changes since the merge base.  We'll use
   the feature change done on MASTER.

 - The other branch, TEST, changed the skin from the merge base, but
   MASTER branch did not change any skinning.  We'll keep the skin change
   done on TEST.

And everything should be fine.

Re: Use case I don't know how to address

[Alan Chandler]

Junio C Hamano wrote:
> Alan Chandler <alan@chandlerfamily.org.uk> writes:
> 
>>        2' - 2a - 3' - 4' ----------------- 6' SITE
>>       /         /    /                    /
>> 1 -  2  ------ 3  - 4  ------------6'''- 6a TEST
>>                      \            /
>>                        5  ------ 6  MASTER
>>                         \         \
>>                           5''- 5a- 6'' DEMO
>>
>>
>> What will happen is the changes made in 4->5 will get applied to the
>> (now) Test branch as part of the 6->6'' merge, and I will be left
>> having to add a new commit, 6a, to undo them all again.  Given this is
>> likely to be quite a substantial change I want to try and avoid it if
>> possible.
> 
> I presume 6'''-6a has the revert of 4-5?  If so, the next merge should
> work just fine.


I think you missed the issue - Yes 6'''-6a is the revert, but the 
problem is this could be large and complicated, and I wanted to find an 
automated way rather than manual

Sort of like doing a diff of 4-5 and somehow applying it backwards.


-- 
Alan Chandler
http://www.chandlerfamily.org.uk

Re: Use case I don't know how to address

[Alan Chandler]

Alan Chandler wrote:
> Junio C Hamano wrote:
>> Alan Chandler <alan@chandlerfamily.org.uk> writes:
>>
>>>        2' - 2a - 3' - 4' ----------------- 6' SITE
>>>       /         /    /                    /
>>> 1 -  2  ------ 3  - 4  ------------6'''- 6a TEST
>>>                      \            /
>>>                        5  ------ 6  MASTER
>>>                         \         \
>>>                           5''- 5a- 6'' DEMO
>>>
>>>
>>> What will happen is the changes made in 4->5 will get applied to the
>>> (now) Test branch as part of the 6->6'' merge, and I will be left
>>> having to add a new commit, 6a, to undo them all again.  Given this is
>>> likely to be quite a substantial change I want to try and avoid it if
>>> possible.
>>
>> I presume 6'''-6a has the revert of 4-5?  If so, the next merge should
>> work just fine.
> 
> 
> I think you missed the issue - Yes 6'''-6a is the revert, but the 
> problem is this could be large and complicated, and I wanted to find an 
> automated way rather than manual
> 
> Sort of like doing a diff of 4-5 and somehow applying it backwards.
> 
> 

I just discovered that git-apply has the -R flag.  Is that what I am 
looking for?

-- 
Alan Chandler
http://www.chandlerfamily.org.uk

Re: Use case I don't know how to address

[Alan Chandler]

Alan Chandler wrote:
> Alan Chandler wrote:
>> Junio C Hamano wrote:
>>> Alan Chandler <alan@chandlerfamily.org.uk> writes:
>>>
>>>>        2' - 2a - 3' - 4' ----------------- 6' SITE
>>>>       /         /    /                    /
>>>> 1 -  2  ------ 3  - 4  ------------6'''- 6a TEST
>>>>                      \            /
>>>>                        5  ------ 6  MASTER
>>>>                         \         \
>>>>                           5''- 5a- 6'' DEMO
>>>>
>>>>
>>>> What will happen is the changes made in 4->5 will get applied to the
>>>> (now) Test branch as part of the 6->6'' merge, and I will be left
>>>> having to add a new commit, 6a, to undo them all again.  Given this is
>>>> likely to be quite a substantial change I want to try and avoid it if
>>>> possible.
>>>
>>> I presume 6'''-6a has the revert of 4-5?  If so, the next merge should
>>> work just fine.
>>
>>
>> I think you missed the issue - Yes 6'''-6a is the revert, but the 
>> problem is this could be large and complicated, and I wanted to find 
>> an automated way rather than manual
>>
>> Sort of like doing a diff of 4-5 and somehow applying it backwards.
>>
>>
> 
> I just discovered that git-apply has the -R flag.  Is that what I am 
> looking for?
> 

         2' - 2a - 3' - 4' ------------ 6' SITE
        /         /    /               /
  1 -  2  ------ 3  - 4  --5'''--5b---6''' TEST
                       \  /          /
                         5  ------ 6  MASTER
                          \         \
                           5''- 5a- 6'' DEMO


Just to be clear - if I do a diff of 4->5 and then immediately merge it 
back to 4 as 5'' (which fast forwards 4) and then 5b is the diff of 4-5 
applied with git apply -R.

Is that what the -R flag does on git apply?

-- 
Alan Chandler
http://www.chandlerfamily.org.uk