[Intel-gfx] The rebasing taboo
Chris Wilson
chris at chris-wilson.co.uk
Tue Sep 14 14:39:23 CEST 2010
As I was pulling together the key branches that I wanted to base -next on,
I made a critical error and included a broken version of a patch that
itself would not be useful until much later.
The patch in question is the start of pipeline support for pageflipping,
ba3d8d74, but alas was broken and in the process of fixing it I realised
we had further bugs in the surrounding areas (some of which would have
been fixed by pipelined fence registers the code for which the broken
patch was a precursor).
Daniel summed up the case for rebasing very well:
1. It is early in the stabilization phase.
2. The patch is clearly broken.
3. The history makes more sense if the patch comes in the with other
cleanups.
What is the best course of action here? As I've yet to send the pull
request to Dave, from his point of view it should be clean to rewrite our
history (as far back as our previous branch point). The other side to
rebasing is that it breaks regression testing, and QA quite rightly
frowns on that.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
More information about the Intel-gfx
mailing list