Handling multiple patches with the same hash in pwclient?

[Tom Rini]

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!

-- 
Tom