This page is an unofficial list of tips that may be useful for committers and other contributors to Django. == Automating Backports == Backporting can be tedious. The following script makes it a bit easier by performing the `git cherry-pick` and modifying the commit message by prepending the branch name and appending "Backport of XXXXXXXX from master.". Put the contents below in `django-src/backport.sh`. Add `backport.sh` to `django-src/.git/info/exclude` to prevent the file from appearing in `git status`. After committing a change to master. Switch to the branch you wish to backport to and execute `./backport `. You can double check the commit message looks ok, then `git push`. {{{ #!/bin/bash BRANCH_NAME=`git branch | sed -n '/\* stable\//s///p'` echo $BRANCH_NAME git reset --hard REV=$1 : ${ORIGBRANCH=master} TMPFILE=tmplog.tmp # Cherry-pick the other commit #ORIGID=`git find-rev r${REV} ${ORIGBRANCH}` #if [ -z "${ORIGID}" ] ; then # echo "Revision ${REV} not found in branch ${ORIGBRANCH}" # exit 1 #fi git cherry-pick ${REV} # Create new log message by modifying the old one git log --pretty=format:"[${BRANCH_NAME}] %s%n%n%b%nBackport of ${REV:0:10} from master" HEAD^..HEAD \ | grep -v '^BP$' > ${TMPFILE} # Commit new log message git commit --amend -F ${TMPFILE} # Clean up temporary files rm -f ${TMPFILE} }}} == Deleting empty directories and pyc files == When switching branches, it's useful to delete directories that don't exist on the branch you're switching to, as well as pyc files so that state from one branch doesn't persist on the new one. Put the following contents in `django-src/.git/hooks/post-checkout` and ensure the file is executable (`chmod +x django-src/.git/hooks/post-checkout`). {{{ #! /bin/sh # Start from the repository root. cd ./$(git rev-parse --show-cdup) # Delete .pyc files and empty directories. find . -name "*.pyc" -delete find . -type d -empty -delete }}} == Running tests == Use the [https://github.com/jphalip/djangocore-box djangocore-box] VM to easily run the Django test suite using different Python versions and different database backends. == Applying patches from Trac or GitHub == [https://gist.github.com/aaugustin/1170400 djpatch.py] will automatically look for the latest patch attached to a ticket, or failing that, for the latest pull request mentioned in the comment, and apply it to your local checkout. == Keeping all upstream branches current locally == I keep this in a script on my path called 'djangoup' {{{ #!/bin/bash git fetch upstream && \ git co stable/1.6.x && git merge --ff-only upstream/stable/1.6.x && \ git co stable/1.5.x && git merge --ff-only upstream/stable/1.5.x && \ git co master && git merge --ff-only upstream/master }}} == Checking test coverage of lines changed/added in a patch == This quick hack checks the coverage of the changes introduced by a given patch https://github.com/ptone/diff-coverage == Quickly run tests on current branch without any specific python env == [yes yes, you can also have your repo installed as -e in a dev env, but this can be handy to know] cd to django/tests and then use one of: {{{ PYTHONPATH=.. python2.7 runtests.py --settings=test_sqlite PYTHONPATH=.. python3.3 runtests.py --settings=test_sqlite }}}