git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
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.


  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).