From: Stefan Sperling Subject: Re: Introduce one-line mode for got tag -l To: Mark Jamsek Cc: Lucas Gabriel Vuotto , gameoftrees@openbsd.org Date: Mon, 23 Dec 2024 11:48:14 +0100 On Mon, Dec 23, 2024 at 01:11:42PM +1100, Mark Jamsek wrote: > Lucas Gabriel Vuotto 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.