Hi Stephen, On Wed, 2012-12-12 at 11:44 +1100, Stephen Rothwell wrote: > Hi Alex, > > On Tue, 11 Dec 2012 17:06:56 -0700 Alex Williamson <alex.williamson@xxxxxxxxxx> wrote: > > > > Is that a bad thing? I can start tagging from my next branch if that's > > preferred. Thanks, > > Linus has said many times to not rebase before sending a pull request. > When you rebase your tree you effectively throw away your testing (since > the thing you rebased on top of may have introduced semantic conflicts > with the work in your tree). If you don't rebase your tested tree, any > conflicts are then restricted to the actual merge and can be fixed there > (or at least the diagnosis will lead there). > > So, if I was a maintiner, at the start of the merge window (or just > before) I would create a test branch that contained my work plus a > *merge* with Linus' tree and do some testing on that and then ask Linus > to pull my tree (not the merged version). It may prove that the test > merge with Linus' tree produces an "interesting" syntactic conflict - in > this case I would mention that to Linus and put the merged tree somewhere > public for him to use as a guide. (Mind you, this conflict would already > have most likely been noted by the linux-next maintainer.) > > Also, your testing may have brought to light a semantic conflict, in > which case the fix could be supplied to Linus with the pull request, or a > well changed logged back merge of Linus' tree containing the fix could be > done and Linus asked to pull the result. Thanks for the tip. I certainly retested after doing the rebase to v3.7, but I can see the point. I'll do as you suggest, a merge on a separate branch for testing only and tag what I currently have in my next branch. v2 forthcoming. Thanks, Alex -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
