Use case I don't know how to address

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.

On Samstag, 5. September 2009, Alan Chandler wrote:

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

Johannes Sixt wrote:

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 <alan@chandlerfamily.org.uk> writes:

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.

Junio C Hamano wrote:

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 wrote:

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

Alan Chandler wrote:

         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?