On Thu, Feb 24, 2011 at 3:55 PM, Paul Menzel <[email protected]> wrote: > it is great that the minutes of the meetings get published. Thank you. > > > Am Donnerstag, den 24.02.2011, 09:20 -0700 schrieb Tom Rini: > > […] > >> Not clear in the summary but from the logs is that we want to, as part >> of making this be transparent, publish guidelines for how this will >> work, based on what poky is doing now. The high level plan is to follow >> the contrib tree model that poky has which means sending pull requests >> (which in turn also post the patches to the ML for review). >> >> For changes that don't have a tree to pull from, someone with write >> access would need to pick them up. > > XBMC is using also an approach with pull requests. The Linux kernel is > doing that also. Is there documentation on how pull requests, merges and > bisecting works together? > > My problem is that pull requests are based on a certain commit in > origin/master. After the request is sent most of the time several > commits are pushed to origin/master in the mean time, so a merge is > necessary “polluting” the commit history.
I don't really see a problem with it, personally. It's not pollution if it's useful information, and recording the point where the branch was brought it can indeed be useful information. > With my current knowledge I find it very difficult to track down bad > commits especially if commits break the builds in between. Does `git > bisect` take care of that itself? How do the Linux developers deal with > that problem, especially merge conflicts? Well, you can mark commits that are broken for unrelated reasons with bisect, but ideally people would use something like git test-sequence combined with rebase to ensure that there are no points in their commits which will break bisect, and *that* gets merged to master. I think it's pretty important to retain bisectability (not a word, I know :) on our branches. -- Christopher Larson clarson at kergoth dot com Founder - BitBake, OpenEmbedded, OpenZaurus Maintainer - Tslib Senior Software Engineer, Mentor Graphics _______________________________________________ Openembedded-devel mailing list [email protected] http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
