On 14 April 2016 at 10:08, Ben Pfaff wrote:
> On Mon, Apr 04, 2016 at 02:56:03PM -0700, Joe Stringer wrote:
>> Previously, whenever a set_field() action was executed, the entire field
>> would become masked and the entire field replaced, regardless of the
>> mask specified in the set_field() actio
On Mon, Apr 04, 2016 at 02:56:03PM -0700, Joe Stringer wrote:
> Previously, whenever a set_field() action was executed, the entire field
> would become masked and the entire field replaced, regardless of the
> mask specified in the set_field() action.
>
> In most cases this is fine, although it ma
On 12 April 2016 at 21:19, Ben Pfaff wrote:
> On Tue, Apr 12, 2016 at 02:23:47PM -0700, Joe Stringer wrote:
>> On 4 April 2016 at 14:56, Joe Stringer wrote:
>> > Previously, whenever a set_field() action was executed, the entire field
>> > would become masked and the entire field replaced, regard
On Tue, Apr 12, 2016 at 02:23:47PM -0700, Joe Stringer wrote:
> On 4 April 2016 at 14:56, Joe Stringer wrote:
> > Previously, whenever a set_field() action was executed, the entire field
> > would become masked and the entire field replaced, regardless of the
> > mask specified in the set_field()
On 4 April 2016 at 14:56, Joe Stringer wrote:
> Previously, whenever a set_field() action was executed, the entire field
> would become masked and the entire field replaced, regardless of the
> mask specified in the set_field() action.
>
> In most cases this is fine, although it may lead to more s
Previously, whenever a set_field() action was executed, the entire field
would become masked and the entire field replaced, regardless of the
mask specified in the set_field() action.
In most cases this is fine, although it may lead to more specific
wildcards than strictly necessary. However, in a
