chrism wrote:
Hi Hans,
On Sun, 25 Jul 2010 13:03:43 -0400, Hans-Christoph Steiner hans@eds.org wrote:
You should add this to the GitWorkflows wiki page on puredata.info.
Ok.
Less commands, yes, but you are omitting then the rebasing stage, which is quite useful if you want to submit clean patches.
I'm about to demonstrate my ignorance of git. :)
When I issue a pull request I was under the impression that the other party could then cherry-pick the exact git commits they want into their own repo, preserving version history, commit meta info, and everything. I've done this on other projects before and it seems to work pretty well. The upstream maintainer can keep those of my commits that they like, and simply not merge the ones they don't like. I don't understand in that context what "clean patches" means.
Chris.
Oftentimes the commit history can be more confusing that useful. So I think the "feature branch" idea is a good one. Basically when you start working on a feature, you start by making a branch. Then you commit early and often, and work out the feature. Once you are ready to submit a patch upstream for someone like Miller to accept it, then you can "git rebase" that feature branch into a clean set of patches, and removing the whole history of commits, including any mistakes, forgotten details, etc. that are often in a commit history.
.hc