Merging (only) subdirectories

This might take a bit of explaining... and for those familiar with it I'm talking about Moodle themes which will help one or two of you.

We develop themes for Moodle. All themes live in their own self-contained directory. So, when creating a new theme we create a new branch (from some version of Moodle - more in a moment) then a new theme folder, do the dev, and commit/push the results.

We have lots of clients and for one reason or another we have lots of different versions of Moodle and/or different customisations. So each client ends up with their own branch.

The problem comes when Client A wants to purchase Theme B. We can't just merge the theme branch because all the rest of the project contains (potentially) a different version of Moodle. So we have to do lots of messing around to get the theme branch in and/or loose the theme commit history in the process.

What I would like to do is to be able to merge branch B into branch A but ONLY stuff that concerns the theme directory. I don't think this is possible. I'm reluctant to keep themes in a completely separate repo as that just makes testing them more problematic.

Does anybody have any thoughts or advice (assuming this all makes sense)?  Cheers!

I would say you are not working best practice with git. The idea of commit is a atomic  change of the whole project.  It seems like you mixed completely unrelated changes in a commit.

You can try as a resolution: git rebase master (on a temporary-branch) git format-patch master

Strip the patches with filterdiff

Apply the stripped patches to another temporary-brach. Merge to the target-Branch.

Best regards
     martin

2010/12/1 "Martin Krüger" <martin.krueger@gmx.com>:

thanks Martin,

There's a whole bunch of stuff there that I am not familiar with so I need to do some reading! When you say we are not using best practices can you elaborate? I am very open to improving the way we do things.

Howard

2010/12/1 "Martin Krüger" <martin.krueger@gmx.com>:

Actually... thinking some more... that was actually my question (sorry if I wasn't clear). We know that we are probably not doing this the best way but we can't work out the right/better way. I'm looking for help to organise our workflow with git better,

Thanks :)

On Wed, Dec 1, 2010 at 6:18 PM, Howard Miller <howard@e-learndesign.co.uk> wrote:

I don't know. Maybe you can use topic branch. The idea is that you and other theme designers branch out from a known point, then make changes in the theme directory only. You guys can merge from each other's tree because nobody would change anything outside theme directory. Occasionally you can merge back upstream for testing with new code, but don't push that merge until your theme is ready. Once your theme rolls out, you can either keep working on your topic branch, or throw it away and branch out again.

Also, please consider submodules if theme dir is totally independent. I don't see how it makes it problematic for testing. git-subtree [1] might be of your interest too.

[1] https://github.com/apenwarr/git-subtree

On 1 December 2010 12:36, Nguyen Thai Ngoc Duy <pclouds@gmail.com> wrote:

Thanks! Again, I need to go and do some reading to see if those things fit my needs.

* Nguyen Thai Ngoc Duy <pclouds@gmail.com> wrote:

Another option could be completely splitting off the themes to their own branches (eg. using git-filter-branch), check them out in an separate workdir and use unionfs to get a combined/merged view of the working trees.

So, you'd actually have to fully separate branches, checked out in their own worktrees/repos:

a) mainapp (the main application) b) theme (the current theme you're working on)

For testing/runtime, the webserver gets a union'ed tree, which just merges both namespaces (from host filesystems's, not git's view) together. Your actual development happens in the theme repo only.

On actual deployment (if you're using git here, too), you can simply merge both branches together (will be just an passive - aka: merge-down-only - branch).

cu

Ok... thanks for that. I'll have a look at that as well.

This type of thing was actually the one thing I can think of that cvs/svn made easy as they keep the repo info in each directory :) (Do I get thrown out for saying that?)

* Howard Miller <howard@e-learndesign.co.uk> wrote:

Besides the fact that their underlying data model makes things like merging particularily hard (svn initially had no branch concept at all ;-o).

BTW: M$-TFS combines the worst of all ...

cu