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....@nxp.com/ > > > http://patchwork.ozlabs.org/project/uboot/patch/20200526233350.25190-1-feste...@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! -- Tom _______________________________________________ Patchwork mailing list Patchwork@lists.ozlabs.org https://lists.ozlabs.org/listinfo/patchwork
