On Mon, Dec 23, 2024 at 01:11:42PM +1100, Mark Jamsek wrote:
> Lucas Gabriel Vuotto <lucas@sexy.is> wrote:
> > As the subject reads. There are 2 commits in here:
> 
> I don't have time to test or review the diff right now but should be
> able to revisit it tonight. I have some comments inline though.
> 
> > - moving tag printing into its own function. I believe I did it in a
> >   error-compatible way, but an extra pair of eyes are more than welcome,
> >   especially because the new function signature is ugly.
> > - adding the actual functionality, lifted from 'log -s'. And here, I
> >   have 2 bikesheds I'd like to remodel:
> >   - I added a shortened tag hash to the output, but idk if it's actually
> >     useful, or if the corresponding commit hash is useful (if it exists?
> >     I'm unsure if that's always the case). Or we can go with only 'date
> >     tagname first-line-of-message'.
> 
> Good thinking!
> 
> I like the idea of emitting a hash purely from a consistency of output
> perspective. I think the tag name must be unique and it can be used
> wherever the tag hash is used, and a tag always points to a git object
> with a hash, usually a commit--and if created with `got tag`, I believe
> it must be a commit--although `git tag` doesn't constrain it to commit
> objects. So maybe something like your suggestion of the commit id would
> provide the most useful condensed output?
> 
> 	$date $objectidpfx $tagname $tagmsgln
> 
> Where $objectidpfx is the abbreviated hash of the commit, tree, blob,
> or tag object at which the tag points.
> 
> OTOH, it might be confusing as users might assume the emitted hash is
> the tag hash even though the documentation would describe the output.

Object type names are short so a type name could be displayed, too.
This would provides a readability hint.

  $date $type:$objectidpfx $tagname $tagmsgln

For got's 0.106 tag this would yield:

  2024-11-21 commit:e9ace9b 0.106 got 0.016

Which leaves us with plenty of space before reaching 80 columns.
The first line of tag messages tends to be short since it usually
just mentions a version number. I wouldn't be too worried about
taking more space away from it.

Perhaps it would be nice to show a colon before the tag message?

  2024-11-21 commit:e9ace9b 0.106: got 0.016

Should we show the full tag reference name? This would be self-documenting
no matter what tag name is used, at a cost of 10 columns:

  2024-11-21 commit:e9ace9b refs/tags/0.106: got 0.016

> >   - given that -s is taken, I used -S for the sake of the patch. But I'd
> >     prefer using -s here too, to keep it in-sync with log. Can '-s
> >     signer' be changed to '-S signer'?
> 
> I, too, would much prefer making it -s for consistency if there are no
> objections shifting current -s to -S signer; and uppercasing it would
> also match with -V for verifying tag object signatures.
> 
> >   And I also have a question: I believe -V doesn't make much sense a
> >   short output. Should I make -S conflict with -V? Or should we still go
> >   ahead and verify tags, and add a simple indicator for whether the
> >   signature is valid or not?
> 
> I agree with you: making them mutually exclusive options makes sense.
 
I agree to all of this, too.