Re: [GIT PULL] VFIO updates for v3.8
Hi Linus, On Tue, 11 Dec 2012 12:08:07 -0700 Alex Williamson alex.william...@redhat.com wrote: The following changes since commit 29594404d7fe73cd80eaa4ee8c43dcc53970c60e: Linux 3.7 (2012-12-10 19:30:57 -0800) are available in the git repository at: git://github.com/awilliam/linux-vfio.git tags/vfio-for-v3.8 for you to fetch changes up to a9e3ccfa452c8c5bac49637fe6ece1ac3246d312: vfio-pci: Enable device before attempting reset (2012-12-11 11:25:37 -0700) This has been rebased from what was in linux-next yesterday onto v3.7. -- Cheers, Stephen Rothwells...@canb.auug.org.au pgpWGWnKCe6EF.pgp Description: PGP signature
Re: [GIT PULL] VFIO updates for v3.8
On Wed, 2012-12-12 at 10:46 +1100, Stephen Rothwell wrote: Hi Linus, On Tue, 11 Dec 2012 12:08:07 -0700 Alex Williamson alex.william...@redhat.com wrote: The following changes since commit 29594404d7fe73cd80eaa4ee8c43dcc53970c60e: Linux 3.7 (2012-12-10 19:30:57 -0800) are available in the git repository at: git://github.com/awilliam/linux-vfio.git tags/vfio-for-v3.8 for you to fetch changes up to a9e3ccfa452c8c5bac49637fe6ece1ac3246d312: vfio-pci: Enable device before attempting reset (2012-12-11 11:25:37 -0700) This has been rebased from what was in linux-next yesterday onto v3.7. Is that a bad thing? I can start tagging from my next branch if that's preferred. Thanks, Alex -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] VFIO updates for v3.8
Hi Alex, On Tue, 11 Dec 2012 17:06:56 -0700 Alex Williamson alex.william...@redhat.com 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. -- Cheers, Stephen Rothwells...@canb.auug.org.au pgpBpXfOShCsR.pgp Description: PGP signature
Re: [GIT PULL] VFIO updates for v3.8
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.william...@redhat.com 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
