On Fri, 12 Nov 2010 08:24:48 -0800, Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> 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 -- Chris Wilson, Intel Open Source Technology Centre _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
