Re: [PATCH 5/9] builtin/cat-file: support "object:type=" objects filter

[Toon Claes <toon@iotcl.com>]

Patrick Steinhardt <ps@pks.im> writes:

> Implement support for the "object:type=" filter in git-cat-file(1),
> which causes us to omit all objects that don't match the provided object
> type.
>
> Signed-off-by: Patrick Steinhardt <ps@pks.im>
> ---
>  Documentation/git-cat-file.adoc | 3 +++
>  builtin/cat-file.c              | 8 +++++++-
>  t/t1006-cat-file.sh             | 6 +++++-
>  3 files changed, 15 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/git-cat-file.adoc b/Documentation/git-cat-file.adoc
> index 8c474418b52..540d9dffdf9 100644
> --- a/Documentation/git-cat-file.adoc
> +++ b/Documentation/git-cat-file.adoc
> @@ -93,6 +93,9 @@ The form '--filter=blob:limit=<n>[kmg]' omits blobs of size at least n
>  bytes or units.  n may be zero.  The suffixes k, m, and g can be used
>  to name units in KiB, MiB, or GiB.  For example, 'blob:limit=1k'
>  is the same as 'blob:limit=1024'.
> ++
> +The form '--filter=object:type=(tag|commit|tree|blob)' omits all objects
> +which are not of the requested type.
>  
>  --path=<path>::
>  	For use with `--textconv` or `--filters`, to allow specifying an object
> diff --git a/builtin/cat-file.c b/builtin/cat-file.c
> index f57bf65cb03..b374c2bb104 100644
> --- a/builtin/cat-file.c
> +++ b/builtin/cat-file.c
> @@ -474,7 +474,8 @@ static void batch_object_write(const char *obj_name,
>  
>  		if (use_mailmap ||
>  		    opt->objects_filter.choice == LOFC_BLOB_NONE ||
> -		    opt->objects_filter.choice == LOFC_BLOB_LIMIT)
> +		    opt->objects_filter.choice == LOFC_BLOB_LIMIT ||
> +		    opt->objects_filter.choice == LOFC_OBJECT_TYPE)
>  			data->info.typep = &data->type;
>  		if (opt->objects_filter.choice == LOFC_BLOB_LIMIT)
>  			data->info.sizep = &data->size;
> @@ -505,6 +506,10 @@ static void batch_object_write(const char *obj_name,
>  			    data->size >= opt->objects_filter.blob_limit_value)
>  				return;
>  			break;
> +		case LOFC_OBJECT_TYPE:
> +			if (data->type != opt->objects_filter.object_type)
> +				return;
> +			break;
>  		default:
>  			BUG("unsupported objects filter");

I see we don't support LOFC_COMBINE, so we won't be supporting repeating
the --filter= option, is this intentional? Should we support that too? I
feel it would make sense from the start, unless there are good reasons
not to?

-- 
Toon