[PD-dev] git workflow idea

Hans-Christoph Steiner hans at at.or.at
Sun Jul 25 20:40:36 CEST 2010


chrism wrote:
> Hi Hans,
> 
> On Sun, 25 Jul 2010 13:03:43 -0400, Hans-Christoph Steiner
> <hans at 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




More information about the Pd-dev mailing list