Johannes Schindelin <johannes.schinde...@gmx.de> writes:
> 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.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
