Handling multiple patches with the same hash in pwclient?

[Stephen Finucane]

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.

Stephen

> Regards,
> Daniel
> 
> 
> 
> > -- 
> > Tom
> > _______________________________________________
> > Patchwork mailing list
> > Patchwork at lists.ozlabs.org
> > https://lists.ozlabs.org/listinfo/patchwork
> _______________________________________________
> Patchwork mailing list
> Patchwork at lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/patchwork