Miller is now pushing his git repository to the pure-data SourceForge project, so we can use git to stay up-to-date and generate patches. This page is to document git workflows useful for contributing code to the core of Pd.
For generating patches straight from Miller's repository
If you want to add a feature by working with Miller's git, then submit that feature as a patch to the patch tracker, this is the way to generate the patch:
-
git clone git://pure-data.git.sourceforge.net/gitroot/pure-data/pure-data (get fresh copy of source code)
-
cd pure-data
-
git checkout -b new_branch (start new branch)
-
git commit (commit all changes to the local branch)
-
git rebase -i (reorganize your commits in the branch into a single clean patch)
-
git log -n2 (get the log of the last two commits)
-
git format-patch <id of the second to last commit>
-
submit to the patch tracker
For generating patches when using your own branched repository
Here's one idea for generating patches based on a given feature. Basically, make a local branch for a feature, commit lots, when done, rebase into clean patches and merge into local master, then submit patch to Miller. Something like:
-
git pull pure-data master (update to latest code from Miller)
-
git checkout -b new_branch (start new branch)
-
git commit (commit all changes to the local branch)
-
git rebase -i ("rebase" the commits in the branch into clean patches"
-
git checkout master (switch to master branch)
-
git pull pure-data master (update to latest code from Miller)
-
git checkout new_branch (switch back to new_branch)
-
git rebase master (merge changes just pulled into master into new_branch)
-
git checkout master (switch back to master)
-
git merge new_branch (merge in new_branch into local master)
-
git branch -d new_branch (delete branch)
-
git push (push changes to your own remote repo)
now make the patch:
-
git log -n2 (get the log of the last two commits)
-
git format-patch <id of the second to last commit>
-
submit to the patch tracker
Keeping your changes ahead of the pure-data master branch
Instead of merging with an upstream repository like pure-data, you might want to keep your changes ahead of the master branch of pure-data. The git manual calls this Keeping a patch series up to date using git rebase. This is the workflow works well if other people are not making commits based on your master. This assumes that you have cloned pure-data and you have set origin to be some remote repository like gitorious and then added pure-data as a remote in .git/config.
-
git checkout -b new_branch (start new branch)
-
work on coding
-
git commit (commit all changes to the local branch)
-
git rebase -i ("rebase" the commits in the branch into clean patches")
-
git checkout master (switch to master branch)
-
git pull origin master (update to latest code from origin)
-
git checkout new_branch (switch back to new_branch)
-
git rebase master (merge changes just pulled into master into new_branch)
-
git checkout master (switch back to master)
-
git merge new_branch (merge in new_branch into local master)
-
git branch -d new_branch (delete branch)
-
git push (push changes to your own remote repo)
now make the patch:
-
git log -n2 (get the log of the last two commits)
-
git format-patch <id of the second to last commit>
-
submit to the patch tracker
now update with newest code from pure-data
-
git checkout pure-data (switch to pure-data tracking branch)
-
git pull pure-data master (get newest code from Miller, but don't merge)
-
git checkout master (switch back to the master)
-
git rebase pure-data (rebase the pd-extended code to be patches against pure-data)
-
git push origin master (push the changes to pd-extended.git)
-
git push origin pure-data (update the pure-data branch in pd-extended.git)
Pd-extended
Pd-extended uses a modified version of the "patch series" workflow above. The rebasing is done in a long-lived patch_series branch, then things are merged into master so that people can work against master. In this case, the patch_series branch serves as a reference, but people should not commit against the patch_series, but always master.
-
git clone git://pure-data.git.sourceforge.net/gitroot/pure-data/pd-extended.git
-
git checkout -b new_branch (start new branch)
-
work on coding...
-
git commit (commit all changes to the local branch)
-
git rebase -i ("rebase" the commits in the branch into clean patches")
-
git checkout master (switch to master branch)
-
git pull origin master (update to latest code from origin)
-
git checkout new_branch (switch back to new_branch)
-
git rebase master (rebase new_branch commits so they based on the latest commits in master)
-
git checkout master (switch back to master)
-
git merge new_branch (merge in new_branch into local master)
-
git branch -d new_branch (delete branch)
now make the patch:
-
git log -n2 (get the log of the last two commits)
-
git format-patch <id of the second to last commit>
-
submit to the patch tracker
Here's Hans' workflow for updating the newest code from pure-data:
-
git checkout pure-data (switch to pure-data tracking branch)
-
git pull pure-data master (get newest code from Miller, but don't merge)
-
git checkout patch_series (switch back to the "patch series" branch)
-
git rebase pure-data (rebase the pd-extended code to be patch_series against pure-data)
-
git checkout master (switch to master branch)
-
git merge pure-data (merge in all changes in pure-data to master branch)
-
git merge patch_series (merge in all changes to master branch)
-
git diff patch_series..master (make sure the code is synced)
-
git push origin master:master (push to the changes to pd-extended.git)
-
git push origin pure-data:pure-data (push to the pure-data branch on pd-extended.git)
-
git push origin patch_series:patch_series (push to the patch_series branch on pd-extended.git)
Here is Hans' workflow adding to Pd-extended:
-
git checkout patch_series (switch back to the "patch series" branch)
-
git checkout -b new_branch (start new branch)
-
work on coding...
-
git commit (commit all changes to the local branch)
-
git rebase -i ("rebase" the commits in the branch into clean patches")
-
git checkout patch_series (switch to patch_series branch)
-
git merge new_branch (merge in new_branch into local master)
-
git branch -d new_branch (delete branch)
Configuring A Public Repository for your git
If you start maintaining a git repo of your own changes to pure-data, then it might make sense to start publishing it somewhere so that people can pull from you easily. Then you'll need to be able to push to your own public repo (e.g. gitorious) and still pull from Miller's repo. To do that, you can set up another remote called pure-data, like used in the above example. Here's stuff to add to your pure-data.git/.git/config:
[remote "origin"]
url = git@gitorious.org:pdvanilla-hcs/pdvanilla-hcs.git
fetch = +refs/heads/*:refs/remotes/origin/*
[remote "pure-data"]
url = git://pure-data.git.sourceforge.net/gitroot/pure-data/pure-data
fetch = +refs/heads/*:refs/remotes/origin/*
[branch "master"]
remote = origin
merge = refs/heads/master
Alternate method
Here is another way to work in your own fork of the master:
-
clone the master repo to disk (git clone)
-
fork the repo on gitorious or github
-
hack, commit and push changes to your own fork (git add; git commit -m; git push url-of-my-fork)
-
issue a pull request to upstream via the gitorious or github website
-
wait for your commits to be merged
-
(and periodically pull the upstream with git pull)
Main Branches
There are two main branches of Miller's pure-data.git:
-
IOhannes m. zmölnig:
http://github.com/umlaeute/pd-vanilla.git
-
Pd-extended:
git://pure-data.git.sourceforge.net/gitroot/pure-data/pd-extended.git