On Mon, Sep 26, 2011 at 5:47 AM, Richard Purdie <richard.pur...@linuxfoundation.org> wrote: > On Mon, 2011-09-26 at 09:27 -0300, Otavio Salvador wrote: >> On Mon, Sep 26, 2011 at 06:23, Richard Purdie >> <richard.pur...@linuxfoundation.org> wrote: >> ... >> > FWIW, something like git cherry can identify your local changes so you >> > could apply them on top of master so there are other ways to make your >> > usecase work... >> >> This breaks the value of using a SCM since you won't have a common parent. >> >> As Chris, I'd prefer to have it merged. >> >> The only way it can complicate issue is if fixes are cherry-picked >> into the stable branch. If they're are done into the stable and merged >> into master this works wonderfully. > > No, this just just plain wrong. Changes go into master which is where > development happens. They can then filter into other branches (there may > be more than one) as needed.
Agreed. No unique changes should generally go into a release or stable branch first. Master is where future development happens by definition. The only time a bugfix should go into the stable/release branch directly is if master has deviated sufficiently such that fixing it there + cherry picking no longer makes sense. I do still think there's a certain amount of value in a periodic merge back, however. Primarily because this encodes knowledge into the repository about the fact that yes, every single fix in the release/stable branch is in fact also in master. Someone looking at the repository, lacking knowledge about our particular branching policies, will be able to see this by use of rev-list/log. Just the other day I was doing a conversion from svn to git for a project and ran into a related issue. There was no merge metadata in svn from the release branches back to master, so now I have to painstakingly step through and make absolutely certain all the fixes went into both. For old releases, this is particularly difficult (and I think is part of otavio's concern), as you can no longer just merge from release/stable to master sanely, due to refactoring, renames, etc on the master branch. -- Christopher Larson clarson at kergoth dot com Founder - BitBake, OpenEmbedded, OpenZaurus Maintainer - Tslib Senior Software Engineer, Mentor Graphics _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
