"GOT", but the "O" is a cute, smiling pufferfish. Index | Thread | Search

From:
Mark Jamsek <mark@jamsek.com>
Subject:
Re: Introduce one-line mode for got tag -l
To:
Stefan Sperling <stsp@stsp.name>
Cc:
Lucas Gabriel Vuotto <lucas@sexy.is>, gameoftrees@openbsd.org
Date:
Tue, 24 Dec 2024 00:26:53 +1100

Download raw body.

Thread
Stefan Sperling <stsp@stsp.name> wrote:
> 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

Yes, very nice! This is even better :)

> 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

I like it!

> 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

And I like this too :)

I'm very much in favour of these suggestions. Thanks, stsp!


-- 
Mark Jamsek <https://bsdbox.org>
GPG: F2FF 13DE 6A06 C471 CA80  E6E2 2930 DC66 86EE CF68