Dealing with duplicated hashes
albert.aribaud at gmail.com
Thu Sep 15 16:38:59 EST 2011
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
> Best regards,
> Wolfgang Denk
More information about the Patchwork