[Server-devel] Looking at edublog moodle code --

Martin Langhoff martin.langhoff at gmail.com
Wed Sep 17 01:37:33 EDT 2008


Hi Tarun,

I'm looking briefly at edublog's moodle code. Was hoping to be able to
cherry-pick the patches making the html editor changes, but your
"initial" moodle commit is with the _modified_ moodle already...?

I am looking at ab1232242ab51336e9b0fc9aed1443bc35fe1d49 - but from
what I can see, that's not a pristine moodle, it's a moodle where
you've made changes already. Correct? Is there a way to separate
those? Do did you base your work on a specific version of moodle(which
I can diff), or did you grab a daily?

What follows is a bit of a style nitpick -- don't take too badly...
it's just that reusing your code is easier if you follow some
guidelines...

First - one topic per commit, only. For example:
- c4a3130ec48cd1fa2eb65fc1e0f59cada1f4b7db "fixes to write upload" is
a good commit dealing with one area / feature
- a1170158d7fb5185287a6a8525aa87718c7959b6 is not so good ;-)

once you are doing that, you can put the area as the 'prefix' in the
first line of your commit. So you write as first lines stuff like...

 xotheme: fixed the frobniz
 oublog: fix db conection in blogger api client
 xift: import of pristine xift framework version 0.1.2.3
 xift: hacked to work on XO

which means that just by scanning the listing in gitk I can spot all
the commits that are important for a particular thing I am looking
for...

In terms of basing your work on something existing - like moodle! -
ideally, you'd be using a branch based on a repo that has all the
history (like the catalyst-maintained moodle-r2 git repo.  That shows
all the moodle history, and then you open up your branch, do your
custom work, and you can also merge in updates (like security fixes)
from upstream.

That's best practice. Second best is to make an initial import of a
'pristine' version, just unpacked from the tarball. Make sure you
mention the exact version in the commit msg. And then make your
changes in separate commits. This means that if you want to re-apply
your changes on a new release of the thing, you have your patches
clearly separated in git.

Anyway, my fault for not looking into your code earlier. It's been a
ton of work on other issues. Now we got to find a way to see how that
initial import commit can be separated into bits I can review and
reuse...

cheers,



m
-- 
 martin.langhoff at gmail.com
 martin at laptop.org -- School Server Architect
 - ask interesting questions
 - don't get distracted with shiny stuff - working code first
 - http://wiki.laptop.org/go/User:Martinlanghoff


More information about the Server-devel mailing list