hey all,
I've been diving into git and trying to figure out a workflow to represent how we work. I think its going to be like a smaller version of the Linux workflow for now at least. I've set up my git to have its master up on gitorious. Then I can "git pull msp master" to pull from Miller's repo on SourceForge. I did this by adding these to puredata.git/.git/config:
[remote "origin"] url = git@gitorious.org:pdvanilla-hcs/pdvanilla-hcs.git fetch = +refs/heads/*:refs/remotes/origin/*
[remote "msp"] url = ssh://eighthave@pure-data.git.sourceforge.net/gitroot/pure-data/pure-data fetch = +refs/heads/*:refs/remotes/origin/*
[branch "master"] remote = origin merge = refs/heads/master
The other key thing I was reading is about "git rebase", it sounds like the "feature branch" workflow will work best for use. 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 msp (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 msp (update to latest code from Miller) - git checkout new_branch (switch back to new_branch) - git rebase master (merge in new_branch into local master)
.hc
----------------------------------------------------------------------------
There is no way to peace, peace is the way. -A.J. Muste
Looks like Hans now speaks git much more fluently than I do :)
One minor comment -- I think this can be adapted to avoid requiring ssh access to sourceforge (so that you don't have to be a pd developer to get into the action) -- just replace ssh://eighthave@pure-data.git.sourceforge.net/... with git://pure-data.git.sourceforge.net/...
The workflow ideas look good to me.
cheers Miller
On Tue, Jul 20, 2010 at 09:42:33PM -0400, Hans-Christoph Steiner wrote:
hey all,
I've been diving into git and trying to figure out a workflow to represent how we work. I think its going to be like a smaller version of the Linux workflow for now at least. I've set up my git to have its master up on gitorious. Then I can "git pull msp master" to pull from Miller's repo on SourceForge. I did this by adding these to puredata.git/.git/config:
[remote "origin"] url = git@gitorious.org:pdvanilla-hcs/pdvanilla-hcs.git fetch = +refs/heads/*:refs/remotes/origin/*
[remote "msp"] url = ssh://eighthave@pure-data.git.sourceforge.net/gitroot/pure-data/pure-data fetch = +refs/heads/*:refs/remotes/origin/*
[branch "master"] remote = origin merge = refs/heads/master
The other key thing I was reading is about "git rebase", it sounds like the "feature branch" workflow will work best for use. 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 msp (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 msp (update to latest code from Miller)
- git checkout new_branch (switch back to new_branch)
- git rebase master (merge in new_branch into local master)
.hc
There is no way to peace, peace is the way. -A.J. Muste
Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Well, I'm learning. Now that I got the basics down, I thought I'd explore git a bit. And it seems that I have another correction to the command workflow:
- git pull msp 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 msp 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>
.hc
On Jul 20, 2010, at 10:00 PM, Miller Puckette wrote:
Looks like Hans now speaks git much more fluently than I do :)
One minor comment -- I think this can be adapted to avoid requiring ssh access to sourceforge (so that you don't have to be a pd developer to get into the action) -- just replace ssh://eighthave@pure-data.git.sourceforge.net/... with git://pure-data.git.sourceforge.net/...
The workflow ideas look good to me.
cheers Miller
On Tue, Jul 20, 2010 at 09:42:33PM -0400, Hans-Christoph Steiner wrote:
hey all,
I've been diving into git and trying to figure out a workflow to represent how we work. I think its going to be like a smaller version of the Linux workflow for now at least. I've set up my git to have its master up on gitorious. Then I can "git pull msp master" to pull from Miller's repo on SourceForge. I did this by adding these to puredata.git/.git/config:
[remote "origin"] url = git@gitorious.org:pdvanilla-hcs/pdvanilla-hcs.git fetch = +refs/heads/*:refs/remotes/origin/*
[remote "msp"] url = ssh://eighthave@pure-data.git.sourceforge.net/gitroot/pure-data/pure-data fetch = +refs/heads/*:refs/remotes/origin/*
[branch "master"] remote = origin merge = refs/heads/master
The other key thing I was reading is about "git rebase", it sounds like the "feature branch" workflow will work best for use. 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 msp (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 msp (update to latest code from Miller)
- git checkout new_branch (switch back to new_branch)
- git rebase master (merge in new_branch into local master)
.hc
There is no way to peace, peace is the way. -A.J. Muste
Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
----------------------------------------------------------------------------
Man has survived hitherto because he was too ignorant to know how to realize his wishes. Now that he can realize them, he must either change them, or perish. -William Carlos Williams
And I put it into a wiki, please add other ideas here too: http://puredata.info/docs/developer/GitWorkflows
.hc
On Jul 20, 2010, at 11:27 PM, Hans-Christoph Steiner wrote:
Well, I'm learning. Now that I got the basics down, I thought I'd explore git a bit. And it seems that I have another correction to the command workflow:
- git pull msp 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 msp 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>
.hc
On Jul 20, 2010, at 10:00 PM, Miller Puckette wrote:
Looks like Hans now speaks git much more fluently than I do :)
One minor comment -- I think this can be adapted to avoid requiring ssh access to sourceforge (so that you don't have to be a pd developer to get into the action) -- just replace ssh://eighthave@pure-data.git.sourceforge.net/... with git://pure-data.git.sourceforge.net/...
The workflow ideas look good to me.
cheers Miller
On Tue, Jul 20, 2010 at 09:42:33PM -0400, Hans-Christoph Steiner wrote:
hey all,
I've been diving into git and trying to figure out a workflow to represent how we work. I think its going to be like a smaller version of the Linux workflow for now at least. I've set up my git to have its master up on gitorious. Then I can "git pull msp master" to pull from Miller's repo on SourceForge. I did this by adding these to puredata.git/.git/config:
[remote "origin"] url = git@gitorious.org:pdvanilla-hcs/pdvanilla-hcs.git fetch = +refs/heads/*:refs/remotes/origin/*
[remote "msp"] url = ssh://eighthave@pure-data.git.sourceforge.net/gitroot/pure-data/pure-data fetch = +refs/heads/*:refs/remotes/origin/*
[branch "master"] remote = origin merge = refs/heads/master
The other key thing I was reading is about "git rebase", it sounds like the "feature branch" workflow will work best for use. 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 msp (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 msp (update to latest code from Miller)
- git checkout new_branch (switch back to new_branch)
- git rebase master (merge in new_branch into local master)
.hc
There is no way to peace, peace is the way. -A.J. Muste
Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Man has survived hitherto because he was too ignorant to know how to realize his wishes. Now that he can realize them, he must either change them, or perish. -William Carlos Williams
----------------------------------------------------------------------------
All mankind is of one author, and is one volume; when one man dies, one chapter is not torn out of the book, but translated into a better language; and every chapter must be so translated.... -John Donne
Hey Hans,
I've found the easiest way to work with git repos is:
* 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 * periodically pull the upstream (git pull)
YMMV, but it means less commands. :)
Chris.
On Tue, 20 Jul 2010 23:27:14 -0400, Hans-Christoph Steiner hans@at.or.at wrote:
Well, I'm learning. Now that I got the basics down, I thought I'd explore git a bit. And it seems that I have another correction to the command workflow:
- git pull msp 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 msp 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>
.hc
On Jul 20, 2010, at 10:00 PM, Miller Puckette wrote:
Looks like Hans now speaks git much more fluently than I do :)
One minor comment -- I think this can be adapted to avoid requiring > ssh access to sourceforge (so that you don't have to be a pd developer to get into the action) -- just replace ssh://eighthave@pure-data.git.sourceforge.net/... with git://pure-data.git.sourceforge.net/...
The workflow ideas look good to me.
cheers Miller
On Tue, Jul 20, 2010 at 09:42:33PM -0400, Hans-Christoph Steiner > wrote:
hey all,
I've been diving into git and trying to figure out a workflow to represent how we work. I think its going to be like a smaller >> version of the Linux workflow for now at least. I've set up my git to have its master up on gitorious. Then I can "git pull msp master" to pull from Miller's repo on SourceForge. I did this by adding these to puredata.git/.git/config:
[remote "origin"] url = git@gitorious.org:pdvanilla-hcs/pdvanilla-hcs.git fetch = +refs/heads/*:refs/remotes/origin/*
[remote "msp"] url = ssh://eighthave@pure-data.git.sourceforge.net/gitroot/pure-data/pure-data fetch = +refs/heads/*:refs/remotes/origin/*
[branch "master"] remote = origin merge = refs/heads/master
The other key thing I was reading is about "git rebase", it sounds like the "feature branch" workflow will work best for use. >> 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 msp (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 msp (update to latest code from Miller)
- git checkout new_branch (switch back to new_branch)
- git rebase master (merge in new_branch into local master)
.hc
There is no way to peace, peace is the way. -A.J. Muste
Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Man has survived hitherto because he was too ignorant to know how to realize his wishes. Now that he can realize them, he must either change them, or perish. -William Carlos Williams
Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Oops messed up that order, here's the corrected one:
- git pull msp (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 msp (update to latest code from Miller) - git checkout new_branch (switch back to new_branch) - git rebase master (merge in changes just pulled into 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) - git push (push changes to your own remote repo)
.hc
On Jul 20, 2010, at 9:42 PM, Hans-Christoph Steiner wrote:
hey all,
I've been diving into git and trying to figure out a workflow to represent how we work. I think its going to be like a smaller version of the Linux workflow for now at least. I've set up my git to have its master up on gitorious. Then I can "git pull msp master" to pull from Miller's repo on SourceForge. I did this by adding these to puredata.git/.git/config:
[remote "origin"] url = git@gitorious.org:pdvanilla-hcs/pdvanilla-hcs.git fetch = +refs/heads/*:refs/remotes/origin/*
[remote "msp"] url = ssh://eighthave@pure-data.git.sourceforge.net/gitroot/pure-data/pure-data fetch = +refs/heads/*:refs/remotes/origin/*
[branch "master"] remote = origin merge = refs/heads/master
The other key thing I was reading is about "git rebase", it sounds like the "feature branch" workflow will work best for use. 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 msp (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 msp (update to latest code from Miller)
- git checkout new_branch (switch back to new_branch)
- git rebase master (merge in new_branch into local master)
.hc
There is no way to peace, peace is the way. -A.J. Muste
----------------------------------------------------------------------------
Programs should be written for people to read, and only incidentally for machines to execute. - from Structure and Interpretation of Computer Programs
-
chrism -
Hans-Christoph Steiner -
Miller Puckette