On Sun, Mar 12, 2017 at 11:01 PM, Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx> wrote: >> So I blame this on flight level 350, but we discussed this at kernel >> summit. Every patch we cherry-pick over comes with a "cherry-picked from >> $sha1" line, as long as you ignore any such sha1 as duplicate you won't >> see the same patch twice. > > I tried that, but that cherry-pick number doesn't seem to match up with > anything in Linus's tree. Where are those numbers coming from? > > Or there aren't numbers at all. Look at commit: > 8726f2faa371514fba2f594d799db95203dfeee0. It just showed up in Linus's > tree, and there's no "cherry-pick" number in there. It ended up in > 4.9.7. > > Hm, ok, you want me to look at the commit id and then search to see if > it's already been merged "before". Ah, that's crazy. So I need to do > that for every i915 patch? Search backwards? Ugh, that's a mess, no > wonder I couldn't figure it out... Our cherry-pick sha1 work exactly like yours: They don't make sense when you only look at the tree a patch has been cherry-picked _to_, since they're the sha1 from the tree they've been cherry-picked _from_. When you clone a fresh copy of your stable tree then the cherry-pick numbers also point nowhere. Only once you've pulled the future tree they're from (Linus' git in your case) do they make sense. Same for our cherry-picks, except the future tree isn't Linus' git (we'd have managed to make sha1 collisions cheaply otherwise ...) but the future Linus' git tree. Which is maintained by Stephen Rothwell in linux-next. As soon as you make sure you have the latest linux-next.git they will all resolve to something meaningful. Not crazy going on at all :-) >> Iirc you said you'll implement this in your scripts, and as long as we >> never break this rule, you'll be fine. Since you seemed to have agreed to >> a solution that would solve all your headaches I didn't bother doing >> any changes on our side here. > > So if a commit says "cherry-pick", I guess I can always assume it's safe > to add, right? If not, _then_ I have to run the "search backwards" > logic, right? > > Ok, let me think about this a bit to see if that's possible to script... Yes, but it shouldn't be hard to avoid the linear search: 1. make sure you have the latest linux-next (to make sure all the sha1 commit-ish resolve to something meaningful). You probably want to do that before you board a plane :-) 2. When you parse an upstream commit that says "commit cherry-picked from $original_sha1", then add a git note for $original_sha1 that you've seen it already and can ignore it. 3. Run that script over v4.9..v4.10 to backfill your git notes branch. 4. Make sure you sync that git notes branch (and if you use git notes already, just use a different git notes branch name to avoid conflicts). 5. When you spot a patch with cc: stable, check for a git note that says you've looked at it (or one of it's cherry-picks) already, if so, silently ignore it. That should massively drop the ratio of failed patches, at least every time I look at your failed patche mail I think they're just double-applied ones. There's ofc a few patches that fail to apply, 3 months of drm/i915 development even wreak the context of simple bugfixes sometimes, but most are not (which is btw why you don't get replies for most of these). -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
