We are also currently struggling with the best way to manage this sort of thing and rebase looks like the best option so far for core tweaks. It has the drawback of making a mess of other people's checked out code when they merge, so we have been thinking of a plan where we tell everyone to commit all changes, then rebase everything off the latest Moodle as a different branch. We can then use the date in the branch name to keep track of what happens, and tell everyone to switch to the new branch.

We have also been looking at this rather nice git branching model by Vincent Driessen and are going to adopt it for all our internal dev work. The strategy there is to always commit any bug fixes on feature branches into the develop branch as well as releases, so you theoretically never really diverge. Moodle doesn't use this way of doing things right now, but it may help to do it more.

If you like that model, BTW, there are some git extensions made by the developer that make it even easier to follow.

Long term, it would be great if Moodle added a hook system akin to Drupal's, which would make core hacks less necessary, but that's another discussion entirely

yes, that works nicely for me with these two scenarios:

* a branch whose only customizations were added files

* a branch with a handful of customizations, including changes to standard Moodle files

Thanks for suggesting it!  And I hope you can get it working for your case.

This was with git version 1.7.7.2.

As a follow-on to Dan's post, for one of our 2.2 upgrades, I've basically followed this procedure but for each feature branch instead of the deployment as a whole, and I've rebased them onto the v2.2.0 tag, rather than the MOODLE_22_STABLE branch.

Each of our feature branches now contains the moodle version - e.g. [customer]-feature-2.2-[feature_name]. This way we can (if we so desire) keep historical branches if we discovered something broke.

I've then created a new staging branch on the v2.2.0 tag, and merged each of our feature branches in.

To make life easier for the next release, as I've gone along, I've also created issues in our local redmine installation to ensure that we don't forget any feature branches in the future (I based this idea after reading something similar in a blog post by Tim Hunt - http://tjhunt.blogspot.com/2011/07/keeping-discipline-of-not-changing.html).

For any upstream fix that we cherry-pick in, we're also creating an issue in our redmine for that.

When 2.3 comes out, we should now be in a much better state so that we can simply:

• take each feature branch and rebase it onto the v2.3.0 tag (should be much easier now I've put the leg work in);
• merge each of the new feature branches into our new staging/deployment branches; and
• check whether each of the upstream fixes we've applied have made it into 2.3, or whether they still need to be included.

To check we've not missed anything, I've also run a git diff against the release tag of our current version, and then applied this to a clean v2.2.0 tag; then compared the diff with our new release.

Andrew

Hi,

And this? (with an existing local_21_STABLE full of customizations tracking MOODLE_21_STABLE)

git checkout -b local_22_STABLE MOODLE_22_STABLE

git format-patch MOODLE_21_STABLE..local_21_STABLE --stdout | git am

There is a significant difference between the results of rebase and the results of patch + am?

Hi Tim,

I have tested this method and it seems to have worked for me upgrading from 2.0 to 2.1. I still have to do some indepth testing to do, but at first glance it looks good. It only threw up 2 conflicts which were pretty trival based on my custom code. The option --strategy-option=patience threw up error as didn't exist, probably due to my git version. I had tried the rebase technique mentioned  below , that was a painful process that didn't work.

Thanks,

Troy

Hi all,

the solution provided by Tim works great for me between a custom branch based on the MOODLE_22_STABLE upgraded to the MOODLE_23_STABLE.

Thanks a lot, it solved me a lot of time and headaches.

all my best

Eric

Yes, it should (and what you type there is the same as what Dan said in his post, the current branch is the default for the last argument). The interesting thing is that this does not work, at least it was not working when Dan and I discussed this on Jabber.