On Wed, Feb 06, 2013 at 04:08:51PM +0100, Michael J Gruber wrote:

> When a command is supposed to use textconv filters (by default or with
> "--textconv") and none are configured then the blob is output without
> conversion; the only exception to this rule is "cat-file --textconv".
> Make it behave like the rest of textconv aware commands.

Makes sense.

> -             if (!textconv_object(obj_context.path, obj_context.mode, sha1, 
> 1, &buf, &size))
> -                     die("git cat-file --textconv: unable to run textconv on 
> %s",
> -                         obj_name);
> -             break;
> +             if (textconv_object(obj_context.path, obj_context.mode, sha1, 
> 1, &buf, &size))
> +                     break;

The implication here is that textconv_object should be handling its own
errors and dying, and the return is always "yes, I converted" or "no, I
did not". Which I think is the case.

> +
> +             /* otherwise expect a blob */
> +             exp_type = "blob";
>       case 0:
>               if (type_from_string(exp_type) == OBJ_BLOB) {

I wondered at first why we needed to set exp_type here; shouldn't we
already be expecting a blob if we are doing textconv? But then I see
this is really about the fall-through in the switch (which we might want
an explicit comment for).

Which made me wonder: what happens with:

  git cat-file --textconv HEAD

It looks like we die just before textconv-ing, because we have no
obj_context.path. But that is also unlike all of the other --textconv
switches, which mean "turn on textconv if you are showing a blob that
supports it" and not "the specific operation is --textconv, apply it to
this blob". I don't know if that is worth changing or not.

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

Reply via email to