Johannes Schindelin <johannes.schindelin@xxxxxx> 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 majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html