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

["brian m. carlson" <sandals@crustytoothpaste.net>]

[-- Attachment #1: Type: text/plain, Size: 3410 bytes --]

On 2020-03-11 at 20:38:46, Junio C Hamano wrote:
> "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.

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

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

> 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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 263 bytes --]