From: Jeff King <peff@peff.net>
Date: Wed, 08 Jul 2020 04:43:47 GMT
Subject: Re: [PATCH v2 0/2] Add support for %(contents:size) in ref-filter
Message-ID: <20200708044347.GB2303891@coredump.intra.peff.net>
In-Reply-To: <CAP8UFD0gUK4TGUA7JZ_V7hFe4LSDAP7DfPyz4gqy1RjLXJPF2w@mail.gmail.com>

On Tue, Jul 07, 2020 at 08:19:06AM +0200, Christian Couder wrote:

> > I'm still not sure why %(objectsize) isn't sufficient here. Is there
> > some use case that's served by %(contents:size) that it wouldn't work
> > for? Or are we just trying to make it more discoverable when you're
> > looking at the contents already?
> 
> %(objectsize) is the size of the whole commit or tag object, while
> %(contents:size) is the size of the complete message (the whole commit
> message or tag message, including trailers and signatures).

Ah, right, that makes sense.

I'd probably use "git log --no-walk --format=%B" or similar for this,
but there is nothing wrong with using for-each-ref (and it is better if
you really do care about properties of the refs themselves, and not just
the commit they point to).

I do think in the long run it might be nice to have a generic
placeholder for "expand this thing and give me the number of bytes", so
we could do:

  %(sizeof:%(contents))

or even:

  %(sizeof:%(authorname) <%(authoremail)>)

but that is definitely outside the scope. If we end up eventually with
a generic mechanism and have to support contents:size forever for
compatibility, I don't think it is that big a problem.

-Peff