Re: [PATCH] convert: legitimately disable clean/smudge filter with an empty override

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



larsxschneider@xxxxxxxxx writes:

> From: Lars Schneider <larsxschneider@xxxxxxxxx>
>
> A clean/smudge filter can be disabled if set to an empty string. However,
> Git will try to run the empty string as command which results in a error
> message per processed file.

The above two sentences do not make any sense to me.  You observe
that the command refuses to work when the variable is set to an
empty string--why then can you claim "filter can be disabled if set
to an empty string"?  I'd consider that the system is not working
with such a configuration, i.e. "filter cannot be disabled by
setting it to empty; such a request will result in an error".

> Teach Git to consider an empty clean/smudge filter as legitimately disabled
> and do not print an error message.

On the other hand, this does make sense to me, as I do not think of
a good way to say "earlier configuration entry said we should use
this filter, but we actually do not want to use that one (or any)"
because a configuration, unlike attributes entry, cannot be reset.
The closest you can do is to set it to empty, so it may be a good
new feature to do this.


--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]