Re: [PATCH 4/4] cat-file: support --textconv/--filters in batch mode

From: Junio C Hamano <gitster@pobox.com>
Date: Aug 18, 2016, 17:08 UTC
Message-ID: <xmqqbn0q6m4v.fsf@gitster.mtv.corp.google.com>
In-Reply-To: <2315ae5ab6918a7c1567f11a64093a860983bc20.1471524357.git.johannes.schindelin@gmx.de>

Johannes Schindelin <johannes.schindelin@gmx.de> writes:

Show 15 quoted lines

> With this patch, --batch can be combined with --textconv or --filters.
> For this to work, the input needs to have the form
>
> 	<object name><single white space><path>
>
> so that the filters can be chosen appropriately.
>  --batch::
>  --batch=<format>::
>  	Print object information and contents for each object provided
> -	on stdin.  May not be combined with any other options or arguments.
> -	See the section `BATCH OUTPUT` below for details.
> +	on stdin.  May not be combined with any other options or arguments
> +	except `--textconv` or `--filters`, in which case the input lines
> +	also need to specify the path, separated by white space.  See the
> +	section `BATCH OUTPUT` below for details.

Makes sense.  This format still allows

	HEAD:<path2> <path1>

i.e. the object name is taken from path2 but we forget it and pretend that the blob sits at path2, which is a good feature.

If I am not mistaken, your cover letter alluded that it might be ideal to take "HEAD:<path>" (nothing else) as input, grab "<path>" and feed that to the filtering machinery, but you decided to stop short of doing that. I actually think that it is the right thing to do for this feature to ignore the trailing :<path> in the object name, iow, I agree with the result from the feature design POV.

The only thing that somewhat is worrysome is what would happen to %(rest). I guess [*1*] it is OK to declare that you cannot use %(rest) in your output format when --filter/--textconv is in use, but if that is the direction we are going, that limitation needs to be documented.

[Footnote]

*1* This is just a "guess", because I do not know what people are using %(rest) for. It is plausible that their use case do not need --filter/--textconv at all, and if that is the case, having this limitation is perfectly fine.