On Wed, Mar 22, 2017 at 06:34:43PM -0400, Santiago Torres wrote:
> > I worked up the patch to do that (see below), but I got stumped trying
> > to write the commit message. Perhaps that is what the test intended, but
> > I don't think tag's --format understands "%G" codes at all. So you
> > cannot tell from the output if a tag was valid or not; you have to check
> > the exit code separately.
> >
> > And if you do something like:
> >
> > git tag -v --format='%(tag)' foo bar |
> > while read tag
> > do
> > ...
> > done
> >
> > you cannot tell at all which ones are bogus. Whereas with the current
> > behavior, the bogus ones are quietly omitted. Which can also be
> > confusing, but I'd think would generally err on the side of caution.
>
> In that case, something like this would be closer to the desired
> behavior?
Yes, though you can spell:
cat >expect <<-\EOF
EOF
as just:
>expect
> I'm also unsure on what would be the right thing to put on the commit
> message.
I think the argument is:
1. It's safer not to expound on tags that have failed verification (so
that the caller cannot accidentally use them). Especially since the
--format cannot tell anything about the GPG status.
That means that
tag=$(git verify-tag --format='%(tag)' foo)
can use a non-blank $tag without having to wonder whether it is
valid or not.
and
2. That's what we've done since the feature was released.
The only thing that would give me pause is if were to later add
%G-like formatters, and then:
xargs git verify-tag --format='%(gpg:status) %(tag)' |
while read status tag
do
...
done
would become useful, but we'd be tied to the behavior that we omit the
tag when the gpg verification failed (for backwards compatibility).
OTOH, we could perhaps make the rule "ignored unless %(gpg) formatters
are used". Which would be backwards-compatible and safe for old formats,
and work correctly for new ones.
-Peff