From: Junio C Hamano <gitster@pobox.com>
To: "brian m. carlson" <sandals@crustytoothpaste.net>
Cc: <git@vger.kernel.org>, Taylor Blau <me@ttaylorr.com>
Subject: Re: [PATCH 2/8] convert: permit passing additional metadata to filter processes
Date: Wed, 11 Mar 2020 13:38:46 -0700 [thread overview]
Message-ID: <xmqq1rpyhbjd.fsf@gitster.c.googlers.com> (raw)
In-Reply-To: <20200310182046.748959-3-sandals@crustytoothpaste.net> (brian m. carlson's message of "Tue, 10 Mar 2020 18:20:40 +0000")
"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" ;-)
> 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.
next prev parent reply other threads:[~2020-03-11 20:38 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-03-10 18:20 [PATCH 0/8] Additional metadata for filter processes brian m. carlson
2020-03-10 18:20 ` [PATCH 1/8] builtin/checkout: pass branch info down to checkout_worktree brian m. carlson
2020-03-10 18:20 ` [PATCH 2/8] convert: permit passing additional metadata to filter processes brian m. carlson
2020-03-11 20:38 ` Junio C Hamano [this message]
2020-03-12 0:39 ` brian m. carlson
2020-03-10 18:20 ` [PATCH 3/8] convert: provide additional metadata to filters brian m. carlson
2020-03-10 18:20 ` [PATCH 4/8] builtin/checkout: compute checkout metadata for checkouts brian m. carlson
2020-03-10 18:20 ` [PATCH 5/8] builtin/clone: compute checkout metadata for clones brian m. carlson
2020-03-15 10:39 ` SZEDER Gábor
2020-03-15 17:44 ` brian m. carlson
2020-03-15 19:30 ` Junio C Hamano
2020-03-10 18:20 ` [PATCH 6/8] builtin/rebase: compute checkout metadata for rebases brian m. carlson
2020-03-10 18:20 ` [PATCH 7/8] builtin/reset: compute checkout metadata for reset brian m. carlson
2020-03-10 18:20 ` [PATCH 8/8] t0021: test filter metadata for additional cases brian m. carlson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: http://vger.kernel.org/majordomo-info.html
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=xmqq1rpyhbjd.fsf@gitster.c.googlers.com \
--to=gitster@pobox.com \
--cc=git@vger.kernel.org \
--cc=me@ttaylorr.com \
--cc=sandals@crustytoothpaste.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).