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.
> 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
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 majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html