Handling multiple patches with the same hash in pwclient?

[Stephen Finucane]

On Wed, 2020-07-08 at 14:45 -0400, Tom Rini wrote:
> On Wed, Jul 08, 2020 at 07:21:03PM +0100, Stephen Finucane wrote:
> > On Fri, 2020-07-03 at 00:06 +1000, Daniel Axtens wrote:
> > > Hi Tom,
> > > 
> > > Thanks for the bug report.
> > > 
> > > > I took the post-commit git hook and made a short shell script out of it,
> > > > to keep patchwork up to date between releases, for our maintainers that
> > > > don't use patchwork directly.  This works fine in most cases, but
> > > > sometimes fails because more than one patch has the same hash.  For
> > > > example:
> > > > http://patchwork.ozlabs.org/project/uboot/patch/20200512093901.14831-2-peng.fan@nxp.com/
> > > > http://patchwork.ozlabs.org/project/uboot/patch/20200526233350.25190-1-festevam@gmail.com/
> > > > give the same hash of "a75890825af3de9740f2d0c5527a72fa33583ae6" and so
> > > > doing something like:
> > > > pwclient info -h a75890825af3de9740f2d0c5527a72fa33583ae6
> > > > 
> > > > fails because there's two valid results, not one.  I see some commands
> > > > support being told to return only the first (or last) N matches, but not
> > > > info.  I assume something on the server side would need changing here,
> > > > rather than the client side, after a quick peek around in pwclient
> > > > sources.  But perhaps I missed something?  Thanks!
> > > 
> > > Hmm yes, I think you're right. pwclient info, when set up to search by
> > > hash, calls into the XMLRPC 'patch_get_by_hash', which will fail on the
> > > server end when there is more than 1 matching patch.
> > > 
> > > We're gently encouraging people to try the new REST API over
> > > XMLRPC. git-pw allows you to interact with patchwork over that API, and
> > > it ... also doesn't seem to expose search-by-hash, although the API does
> > > support it:
> > > 
> > > http://patchwork.ozlabs.org/api/patches/?project=uboot&hash=a75890825af3de9740f2d0c5527a72fa33583ae6
> > > 
> > > (the query is weirdly slow, especially without specifying a
> > > project. guess we should look into that.)
> > > 
> > > Anyway, with regards to the gap in git-pw, pinging Stephen...
> > > Also Stephen knows pwclient much better than I so he might have some
> > > ideas there too.
> > 
> > Not a whole lot to be done for pwclient. As Daniel noted, we're moving
> > on from the XML-RPC API but the pwclient migration to the REST API
> > isn't complete yet. Even when it is, this is awkward to solve because
> > the hash field isn't unique so we can't add an identical ability to the
> > REST API (i.e. '/api/patches/{hash}').
> > 
> > With that said, I'll push up a release of git-pw shortly which should
> > allow you to filter on patches using 'git-pw patch list --hash HASH'.
> > That's not going to resolve the actual duplicate hash but it'll let you
> > retrieve whatever Patchwork has via the REST API and determine what to
> > do from there.
> 
> What I was thinking was that since other hash searches let you limit to
> first/last N matches, something like that would be what I need (my use
> case would be the last match as that's going to be the latest and so
> what I apply).  Is that workable?  Thanks!

Sure. You want to include 'sort=-date&per_page=1' in the above query,
which will sort by reverse date (newest first) and only show one entry.
So:

  GET http://patchwork.ozlabs.org/api/patches/?project=uboot&hash=${hash}&sort=-date&per_page=1

You should be able to use curl to pull this in and something like 'jq'
to get the information you want. Once you have the ID of the patch,
simply update. There's lots of info in the docs [1] about this.

Hopefully that makes sense.
Stephen

[1] https://patchwork.readthedocs.io/en/latest/api/rest/