Re: [PATCH 2/8] convert: permit passing additional metadata to filter processes

From: Junio C Hamano <gitster@pobox.com>
Date: Mar 11, 2020, 20:38 UTC
Message-ID: <xmqq1rpyhbjd.fsf@gitster.c.googlers.com>
In-Reply-To: <20200310182046.748959-3-sandals@crustytoothpaste.net>

"brian m. carlson" <sandals@crustytoothpaste.net> writes:

> From: "brian m. carlson" <bk2204@github.com>

Do you want this name/address associated to your contributions? I am asking because to me you have always been "that toothpaste guy" ;-)

Show 22 quoted lines

> There are a variety of situations where a filter process can make use of
> some additional metadata.  For example, some people find the ident
> filter too limiting and would like to include the commit or the branch
> in their smudged files.  This information isn't available during
> checkout as HEAD hasn't been updated at that point, and it wouldn't be
> available in archives either.
>
> Let's add a way to pass this metadata down to the filter.  We pass the
> blob we're operating on, the treeish (preferring the commit over the
> tree if one exists), and the ref we're operating on.  Note that we won't
> pass this information in all cases, such as when renormalizing or when
> we're performing diffs, since it doesn't make sense in those cases.
>
> This series wires up the code to print this information, but doesn't
> pass any of it at this point.  In a future commit, we'll have various
> code paths pass the actual useful data down.
> ...
> +struct checkout_metadata {
> +	const char *refname;
> +	struct object_id treeish;
> +	struct object_id blob;
> +};

The "filter" you talk about is the clean/smudge kind of thing that works on individual blobs, and the series is about giving a bit more information than the raw contents to be filtered. I am assuming that I got at least that part correctly.

Now, a few questions.

Is "refname" "refs/heads/branch? when I run "git checkout branch" or "git checkout branch -- Makefile"? Is "treeish" the same as the output from "rev-parse branch^{commit}" in such a case?

Assuming they are, what refname and treeish does my filter see, when the user did these things?

    git checkout origin/master
    git checkout v1.2.3
    git checkout v1.2.3~4

As a writer of a filter, do I get different clues when I am munging Documentation/Makefile and t/Makefile, when the user does

    git checkout master -- Makefile Documentation/Makefile

i.e. grab these two files out of the tree of the commit at the tip of the master branch?

Or do I just learn what the "refname" (presumably "refs/heads/master"?) and treeish (presumably "rev-parse master^{commit}") and I cannot tell where in that tree hierarchy the contents come from?

Thanks.