Re: [PATCH v6 12/13] convert: add filter.<driver>.process option

From: Jakub Narębski <jnareb@gmail.com>
Date: Aug 31, 2016, 13:14 UTC
Message-ID: <f02e2a1d-7e42-2cf8-9b0d-02034e560835@gmail.com>
In-Reply-To: <20160831045713.GA15209@tb-raspi>

Hi,

W dniu 31.08.2016 o 06:57, Torsten Bögershausen pisze:

> On Tue, Aug 30, 2016 at 03:23:10PM -0700, Junio C Hamano wrote:
>> Lars Schneider <larsxschneider@gmail.com> writes:
>>> On 30 Aug 2016, at 20:59, Junio C Hamano <gitster@pobox.com> wrote:

Torsten, could you please in the future remove irrelevant parts of the cited email you are responding to? Thanks in advance,

[...]

Show 14 quoted lines

>>>> I meant it as primarily an example people can learn from when they
>>>> want to write their own.
>>>
>>> I think `t/t0021/rot13-filter.pl` (part of this patch) serves this purpose 
>>> already.
>>
>> I would expect them to peek at contrib/, but do you seriously expect
>> people to comb through t/ directory?
> 
> How about a filter written in C, and placed in ./t/helper/ ?
>
> At least I feel that a filter in C-language could be a starting point
> for others which prefer, depending on the task the filter is going to do,
> to use shell scripts, perl, python or any other high-level language.

People do not look into t/helper/ area, but they do into contrib/. Git provides examples on how to use its features there (among other things). Examples for how use the fast-import feature / protocol are here, in contrib/fast-import.

I think that C language would be not a good choice, as required
low level wrangling of the protocol would obscure the relevant parts,
... well perhaps except if pkt-line was reused.  High-level language
would be better.  The contrib/fast-import directory includes examples
in shell script, Perl and Python.  The same could be done here
(possibly with more languages).

> A test case, where data can not be filtered, would be a minimum.
> As Jakub pointed out, you can use iconv with good and bad data.

The iconv might be good example, but I think it is not a practical one; are there development environments that do not handle UTF-8?

More practical would be to have for example LFS-ish solution of storing files as-is in a specified directory. ROT13 is also good, if not a very practical example. Or rezipping all ZIP-compression based files (ODF, JAR/WAR, DOCX / OOXML, CBZ, EPUB, APK, etc.).

-- 
Jakub Narębski