From: Lars Schneider <larsxschneider@gmail.com>
To: Junio C Hamano <gitster@pobox.com>
Cc: Git Users <git@vger.kernel.org>, Jeff King <peff@peff.net>
Subject: Re: [PATCH] convert: legitimately disable clean/smudge filter with an empty override
Date: Thu, 28 Jan 2016 10:27:20 +0100 [thread overview]
Message-ID: <AB5433EB-2C86-4A71-9E9F-057AC3CC150A@gmail.com> (raw)
In-Reply-To: <xmqqr3h6bgbe.fsf@gitster.mtv.corp.google.com>
On 25 Jan 2016, at 02:25, Junio C Hamano <gitster@pobox.com> wrote:
> larsxschneider@gmail.com writes:
>
>> From: Lars Schneider <larsxschneider@gmail.com>
>>
>> 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".
If I am not mistaken then Git exits with 0 (success) and an error message
if the filter command is empty and the filter is not required. If the filter
command is empty and the filter is required then Git will exit with 1 (error).
How about this?
If the clean/smudge command of a Git filter driver (filter.<driver>.smudge and
filter.<driver>.clean) is set to an empty string ("") and the filter driver is
not required (filter.<driver>.required=false) then Git will run successfully.
However, Git will print an error for every file that is affected by the filter.
Teach Git to consider an empty clean/smudge filter as legitimately disabled
and do not print an error message if the filter is not required.
Thanks,
Lars
>
>> 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.
>
>
next prev parent reply other threads:[~2016-01-28 9:28 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-01-24 12:22 [PATCH] convert: legitimately disable clean/smudge filter with an empty override larsxschneider
2016-01-24 15:06 ` Torsten Bögershausen
2016-01-24 21:35 ` Eric Sunshine
2016-01-27 9:49 ` Lars Schneider
2016-01-27 9:42 ` Lars Schneider
2016-01-24 21:45 ` Jeff King
2016-01-27 9:50 ` Lars Schneider
2016-01-25 1:25 ` Junio C Hamano
2016-01-28 9:27 ` Lars Schneider [this message]
2016-01-28 22:06 ` Junio C Hamano
2016-01-28 23:51 ` Junio C Hamano
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=AB5433EB-2C86-4A71-9E9F-057AC3CC150A@gmail.com \
--to=larsxschneider@gmail.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=peff@peff.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).