On Fri, 12 Nov 2010 08:24:48 -0800, Linus Torvalds torvalds@linux-foundation.org wrote:
But when you cherry-pick it from some random internal tree that nobody will necessarily ever see, and that you don't even describe what it is, it's only pure confusion. I do
[torvalds@i5 linux]$ git show 6aa56062eaba67adfb247cded244fd877329588d fatal: bad object 6aa56062eaba67adfb247cded244fd877329588d
and so will everybody else. So from a documentation standpoint, you're actually adding negative information. Please don't.
My bad, I cherry-picked it from our public drm-intel-next tree and thought it wise to include the cross-reference to explain the duplication and merge conflicts and to provide some additional test history into the commit. Obviously not enough information.
Is there a right approach here? I'm trying to be strict in that what is sent upstream in -fixes are purely known regression fixes, and to preserve test history on both -fixes and -next. That leads to situations like the above where we have a commit that does not appear to relevant to stable at first, but then is later shown to be required. How best to resolve the eventual conflict that will show up in your tree? Just cherry-pick and be dammed? -Chris