Dealing with duplicated hashes

Albert ARIBAUD albert.aribaud at
Thu Sep 15 16:38:59 EST 2011

Hi all,

Le 15/09/2011 08:10, Wolfgang Denk a écrit :
> Dear Jeremy Kerr,
> In message<1316064427.2768.40.camel at pororo>  you wrote:
>>> I came to the conclusion that the current behaviour is actually a bug.
>>> I have seen cases where new patch versions were sent because changes
>>> to the commit message were requested - yet pwclient will always access
>>> the old patch, and thus eventually apply the wrong one.
>> Yeah, bug or not, it's definitely not desirable behaviour.
>> However, solving it in a comprehensive way doesn't seem obvious - we
>> could return an error when there are multiple hash matches, or perhaps
>> default to the most recent patch. But both of these are a little
>> imprescice, will this be okay for your usage?
> I think there are two use cases:
> - In most cases we want to use the most recent one. So this should be
>    the default.
>    If there are multiple hash matches, it would probably be helpful if
>    a warning was issued (which might, for example, contain the numbers
>    of the matching patches and their states).
> - In some cases (when changing state) it would be nice to be able to
>    operate on all patches at once; maybe pwclient could have some
>    "--all" flag for such cases?

Sounds good to me, with two nitpicks:


"--all" does not look like it is about matching hashes. I would suggest 
something like "--all-hash-matches" (quite long, I admit) or 

But seeing as pwclient seems to be short-option-forms only, I'd settle 
for "-H <hash>" (capital H) for "apply to all patches matching the hash" 
and "-h" for "apply only to the latest patch". :)


When applying state "Accepted" to the newest of hash-matching patches, 
we don't want "Accepted" applied to other matching patches; at most, we 
want them to go "Superseded" -- but I imagine this was implied in 
Wolfgang's suggestion.

> Thanks!
> Best regards,
> Wolfgang Denk


More information about the Patchwork mailing list