Johannes Schindelin <> 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


*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
More majordomo info at

Reply via email to