[RFC] ref-filter: add new atom `signature`

[RFC] ref-filter: add new atom `signature`

[Hariom verma]

Hi,

In ref-filter, we have a bunch of atoms which serves as a formatting
option for `git for-each-ref`.

Despite of having 'subject' as an argument to 'contents' [i.e
`%(contents:subject)`], we still have 'subject' as an atom [i.e
`%(subject)`].
Likewise for `%(contents:signature)`, we can have 'signature' as an atom too.

Currently, `%(contents:signature)` internally uses `parse_signature()`
that only works for signed tag objects. I plan to expand the scope of
`signature` by defining it as an atom and will make it work for
commits too.
Also, thinking of adding `signer`, `key`, `fingerprint`,
`primarykeyfingerprint`, `trustlevel` and `grade`[print 'G' for good,
'B' for bad...] as arguments to "signature".

This change will also help me in using ref-filter's logic in pretty.c
for formatting options like "GG", "G?", etc. To know more about these
formatting options, you can take a look here[1].

If curious about what approach I'm taking for using ref-filter logic
in pretty.c, see[2]

Would love hear your thoughts on it. Any suggestions will also be appreciated.

Thanks,
Hariom

[1]: https://github.com/git/git/blob/f402ea68166bd77f09b176c96005ac7f8886e14b/Documentation/pretty-formats.txt#L221-L235
[2]: https://public-inbox.org/git/pull.658.git.1592218662.gitgitgadget@gmail.com/

Re: [RFC] ref-filter: add new atom `signature`

[Christian Couder]

Hi,

On Sun, Jun 28, 2020 at 12:05 PM Hariom verma <hariom18599@gmail.com> wrote:
>
> Hi,
>
> In ref-filter, we have a bunch of atoms which serves as a formatting
> option for `git for-each-ref`.

Ok.

> Despite of having 'subject' as an argument to 'contents' [i.e
> `%(contents:subject)`], we still have 'subject' as an atom [i.e
> `%(subject)`].
> Likewise for `%(contents:signature)`, we can have 'signature' as an atom too.

Ok. Some things are available in different ways perhaps because of
historical reasons and backward compatibility.

> Currently, `%(contents:signature)` internally uses `parse_signature()`
> that only works for signed tag objects. I plan to expand the scope of
> `signature` by defining it as an atom and will make it work for
> commits too.

Didn't you say already that "we can have 'signature' as an atom too",
so isn't it already defined as an atom? Does `%(contents:signature)`
work for commits while '%(signature)' doesn't? And what happens when
it doesn't work?

> Also, thinking of adding `signer`, `key`, `fingerprint`,
> `primarykeyfingerprint`, `trustlevel` and `grade`[print 'G' for good,
> 'B' for bad...] as arguments to "signature".

Ok, I guess all the above arguments would be new.

> This change will also help me in using ref-filter's logic in pretty.c
> for formatting options like "GG", "G?", etc. To know more about these
> formatting options, you can take a look here[1].
>
> If curious about what approach I'm taking for using ref-filter logic
> in pretty.c, see[2]
>
> Would love hear your thoughts on it. Any suggestions will also be appreciated.

It would be nice to see, at least for the atoms or arguments that you
are planning to, or have already, worked on, a list showing how each
formatting option in pretty.c maps to one or more atoms possibly with
arguments.

For example something like:

%GS: show the name of the signer for a signed commit
  maps to: %(signature:signer)
  status: yet to be implemented

Thanks,
Christian.

Re: [RFC] ref-filter: add new atom `signature`

[Hariom verma]

Hi,

On Wed, Jul 1, 2020 at 3:23 PM Christian Couder
<christian.couder@gmail.com> wrote:
>
> Hi,
>
> On Sun, Jun 28, 2020 at 12:05 PM Hariom verma <hariom18599@gmail.com> wrote:
> >
> > Hi,
> >
> > In ref-filter, we have a bunch of atoms which serves as a formatting
> > option for `git for-each-ref`.
>
> Ok.
>
> > Despite of having 'subject' as an argument to 'contents' [i.e
> > `%(contents:subject)`], we still have 'subject' as an atom [i.e
> > `%(subject)`].
> > Likewise for `%(contents:signature)`, we can have 'signature' as an atom too.
>
> Ok. Some things are available in different ways perhaps because of
> historical reasons and backward compatibility.

Okay.

> > Currently, `%(contents:signature)` internally uses `parse_signature()`
> > that only works for signed tag objects. I plan to expand the scope of
> > `signature` by defining it as an atom and will make it work for
> > commits too.
>
> Didn't you say already that "we can have 'signature' as an atom too",
> so isn't it already defined as an atom? Does `%(contents:signature)`
> work for commits while '%(signature)' doesn't? And what happens when
> it doesn't work?

Sorry for the ambiguity in my statement.
- Only `contents` exists as an atom, which accepts `signature` as an
argument. i.e '%(contents:signature)'
- 'signature' does not exist as an atom. I plan to add this.
- `%(contents: signature)` only works for tag objects. For commit it
prints nothing.

> > Also, thinking of adding `signer`, `key`, `fingerprint`,
> > `primarykeyfingerprint`, `trustlevel` and `grade`[print 'G' for good,
> > 'B' for bad...] as arguments to "signature".
>
> Ok, I guess all the above arguments would be new.

Yes

> > This change will also help me in using ref-filter's logic in pretty.c
> > for formatting options like "GG", "G?", etc. To know more about these
> > formatting options, you can take a look here[1].
> >
> > If curious about what approach I'm taking for using ref-filter logic
> > in pretty.c, see[2]
> >
> > Would love hear your thoughts on it. Any suggestions will also be appreciated.
>
> It would be nice to see, at least for the atoms or arguments that you
> are planning to, or have already, worked on, a list showing how each
> formatting option in pretty.c maps to one or more atoms possibly with
> arguments.
>
> For example something like:
>
> %GS: show the name of the signer for a signed commit
>   maps to: %(signature:signer)
>   status: yet to be implemented
>

Yeah, that would be nice.

## User Formats

%H: commit hash
maps to: "%(objectname)"
status: Implemented

%h: abbreviated commit hash
maps to: "%(objectname:short)"
status: Implemented

%T: tree hash
maps to: "%(tree)"
status: Implemented

%t: abbreviated tree hash
maps to: "%(tree:short)"
status: Implemented

%P: parent hashes
maps to: "%(parent)"
status: Implemented

%p: abbreviated parent hashes
maps to: "%(parent:short)"
status: Implemented

%an: author name
maps to: "%(authorname)"
status: Implemented

%ae: author email
maps to: "%(authoremail)"
status: Implemented

%ad: author date
maps to: "%(authordate)"
status: Implemented

%cn: committer name
maps to: "%(committername)"
status: Implemented

%ce: committer email
maps to: "%(committeremail)"
status: Implemented

%cd: committer date
maps to: "%(committerdate)"
status: Implemented

%s: subject
maps to: "%(subject)"
status: Implemented

%f: sanitized subject line, suitable for a filename
maps to: "%(subject:sanitize)"
status: Implemented

%b: body
maps to: "%(body)"
status: Implemented

%GG: raw verification message from GPG for a signed commit
maps to: %(signature)
status: Implemented

%G?: show "G" for a good (valid) signature, "B" for a bad signature...
maps to: "%(signature:grade)"
status: In progress

%GS: show the name of the signer for a signed commit
maps to: "%(signature:signer)"
status: Implemented

%GK: show the key used to sign a signed commit
maps to: "%(signature:key)"
status: Implemented

%GF: show the fingerprint of the key used to sign a signed commit
maps to: "%(signature:fingerprint)"
status: Implemented

%GP: show the fingerprint of the primary key whose subkey was used to
sign a signed commit
maps to: "%(signature:primarykeyfingerprint)"
status: Implemented

%GT: show the trust level for the key used to sign a signed commit
maps to: "%(signature:trustlevel)"
status: In progress

## Commit Formats

Note: This is only for the commit body[as pretty.c only handles commit
body]. First line that contains `commit hash` is handled by
log-tree.c, So no need to map it.

'oneline'
maps to: "%(subject)"
status: implemented

'short'
maps to: "Author: %(authorname) %(authoremail)\n\n\t%(subject)\n"
status: Implemented

'medium'
maps to: "Author: %(authorname)
%(authoremail)\nDate:\t%(authordate)\n\n%(subject)\n\n%(body)"
status: Implemeted

'full'
maps to: "Author: %(authorname) %(authoremail)\nCommit:
%(committername) %(committeremail)\n\n%(subject)\n\n%(body)"
status: Implemented

'fuller'
maps to: "Author:\t\t%(authorname)
%(authoremail)\nAuthorDate:\t%(authordate)\nCommit:\t\t%(committername)
%(committeremail)\nCommitDate:\t%(committerdate)\n\n%(subject)\n\n%(body)"
status: Implemented

'raw'
status: Not yet Implemented

Thanks,
Hariom