> > >> >
> > >> > > > (cherry picked from commit 50aec9665e0babd62b9eee4e613d9a1ef8d2b7de)
> > >> >
> > >> > Would help out here, but it doesn't.
> > >>
> > >> I wonder if there would be a way of automate this on stable scripts
> > >> to avoid attempting a cherry pick that is already there.
> > >
> > > Please tell me how to do so.
> > >
> > >> But I do understand that any change like this would cause a 'latency'
> > >> on the scripts and slow down everything.
> > >
> > > Depends, I already put a huge latency on drm stable patches because of
> > > this mess. And I see few, if any, actual backports for when I report
> > > FAILED stable patches, so what is going to get slower than it currently
> > > is?
My thought was on the stable scripts doing something like that.
For each candidate commit, check if it has the tag line
(cherry picked from commit <original-hash>)
if so, then something like:
if git rev-parse --quiet --verify <original-hash> || \
git log --grep="cherry picked from commit <original-hash> -E --oneline >/dev/null; then
echo "One version of this patch is already in tree. Skipping..."
# send-email?!
else
#attempt to apply the candidate commit...
> > > Normally you all tag these cherry-picks as such. You didn't do that
> > > here or either place, so there was no way for anyone to know. Please
> > > fix that.
I'm afraid this is not accurate. Our tooling is taking care of that for us.
More details below.
> > To be fair, this one seems to have been an accident. The same commit was
> > cherry-picked to *two* different branches by two different people
> > [1][2], and this is something we try not to do. Any cherry-picks should
> > go to one tree only, it's checked by our scripts, but it's not race free
> > when two people are doing this roughly at the same time.
Also I don't believe there's anything wrong here. It was a coincidence on
the timing, but one is
drm-xe-next-fixes-2024-05-09-1
and the other
drm-xe-fixes-2024-05-09
both maintained by different people at that time.
>
> any cherry-pick SHOULD have the git id referenced when they are
> cherry-picked, that's what the id is there for. Please always do that.
Original commit hash is 50aec9665e0babd62b9eee4e613d9a1ef8d2b7de
50aec9665e0b ("drm/xe: Use ordered WQ for G2H handler")
drm-xe-next-fixes-2024-05-09-1
has commit 2d9c72f676e6 ("drm/xe: Use ordered WQ for G2H handler")
which contains:
(cherry picked from commit 50aec9665e0babd62b9eee4e613d9a1ef8d2b7de)
Signed-off-by: Thomas Hellström <thomas.hellstrom@xxxxxxxxxxxxxxx>
drm-xe-fixes-2024-05-09
has commit c002bfe644a2 ("drm/xe: Use ordered WQ for G2H handler")
which contains:
(cherry picked from commit 50aec9665e0babd62b9eee4e613d9a1ef8d2b7de)
Signed-off-by: Lucas De Marchi <lucas.demarchi@xxxxxxxxx>
Perhaps git itself should be smart to avoid it since the info is there,
but unfortunately it is not. So probably a script on top like above
could help us to minimize cases like this.
Thanks a lot from the support and patience here.
>
> greg k-h
