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

From: brian m. carlson <sandals@crustytoothpaste.net>
Date: Mar 12, 2020, 00:39 UTC
Message-ID: <20200312003906.GC6198@camp.crustytoothpaste.net>
In-Reply-To: <xmqq1rpyhbjd.fsf@gitster.c.googlers.com>

On 2020-03-11 at 20:38:46, Junio C Hamano wrote:

Show 6 quoted lines

> "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" ;-)

Yes, this is something I wrote as part of my job. I mostly work on non-Git things there, but occasionally I do some Git work, and I attach a work email to commits I do at work and a personal email to things I do outside of work. This is so for licensing reasons: I have the ability to grant libgit2 or other folks permission to use stuff I wrote on personal time, but I would need to ask first for things written on GitHub's time, and I am really terrible at remembering why I wrote what code.

There's already a .mailmap entry that maps everything to the same person.

You should continue to see most of my contributions come from my personal address, since most of what I contribute to Git is just for fun.

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

You have indeed.

Show 5 quoted lines

> 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?

Yes, we'll get something like the following:

  command=smudge
  ref=refs/heads/master
  treeish=16f09066000e3328fb2d5c54beb55fc25c1af15c
  blob=c8e324426dccfcfebad5c33c8ffb97d5a2b54a67
  can-delay=1
  pathname=test99.bin

The treeish is, in this case, git rev-parse refs/heads/master^{commit}. It will always be the commit unless we have no commit, in which case it will be the tree.

Show 6 quoted lines

> 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

We get no ref for these, because HEAD doesn't (well, won't) point to anything other than a branch, and a treeish pointing to a commit, plus a blob and a pathname for each individual blob.

I tried to emulate the "read HEAD" behavior as much as possible for refnames, but if people would like a ref in these cases, I can do that.

Show 11 quoted lines

> 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?

We already pass the pathname when processing a file; this is guaranteed.

I clearly need to update the commit message to explain this better for future readers, since you should not have to ask questions about what output the series provides, so I'll do that when I reroll. I'll see if anyone else has any feedback, and then do that.

-- 
brian m. carlson: Houston, Texas, US
OpenPGP: https://keybase.io/bk2204