Messages in this thread | | | Subject | Re: [GIT PULL] VFIO updates for v3.8 | From | Alex Williamson <> | Date | Tue, 11 Dec 2012 19:59:32 -0700 |
| |
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@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
| |