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