Patrick Steinhardt <ps@xxxxxx> 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@xxxxxx>
> ---
> 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
