Version 14 (modified by Natalia Bidart, 16 months ago) ( diff )

--

This page is an unofficial list of tips that may be useful for committers and other contributors to Django.

Versions of several of the scripts given below can be found in https://github.com/shaib/django-developer-tools.

Pushing to a pull request branch

Add to .bashrc:

#!/bin/bash
function prp(){
    IFS=':' read -r -a array <<< "$1"
    url=`git config --get remote.origin.url`
    url=`echo $url | sed -e "s/:.*\//:${array[0]}\//g"`
    git push -f $url HEAD:${array[1]}
}

Usage: $ prp username:branch_name

Copy username:branch_name from the pull request page.

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 <full hash> from main.".

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 main. Switch to the branch you wish to backport to and execute ./backport <full hash of commit to backport>. If there are no conflicts, you can double check the commit message looks ok, then git push.

If there is any conflict, make sure to properly fix it, then run git add on the conflicted files, and continue with the cherry pick with git cherry-pick --continue. Please note that in this case, you will have to manually amend the commit so it has the proper branch name prefix (e.g. [4.2.x]). Review your changes, and only then push them upstream.

#!/bin/bash
if [ -z $1 ]; then
    echo "Full hash of commit to backport is required."
    exit
fi

BRANCH_NAME=`git branch | sed -n '/\* stable\//s///p'`
echo $BRANCH_NAME

git reset --hard

REV=$1
: ${ORIGBRANCH=main}

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} from main" 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 djangocore-box VM to easily run the Django test suite using different Python versions and different database backends.

Applying patches from Trac or GitHub

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 main && git merge --ff-only upstream/main

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
Note: See TracWiki for help on using the wiki.
Back to Top