Re: [PATCH man] landlock.7: Re-group description of IOCTL access right

[Alejandro Colomar <alx@kernel.org>]

[-- Attachment #1: Type: text/plain, Size: 3153 bytes --]

On Tue, Jan 13, 2026 at 08:18:59PM +0100, Günther Noack wrote:
> Hi Alejandro!

Hi Günther!

[...]
> > > 
> > > The same change was also done in kernel documentation, linked below.
> > > 
> > 
> > Could you please add a Fixes: tag?
> 
> Done. Thanks for sharing the handy git alias as well - this is very
> neat, I added that to my toolbox :)

Nice!  :)

BTW, I should explain the rationale for the format.  I based it on two
things: the format used in the kernel, which is

	12-char-hash ("commit-subject")

and 'git log --pretty=reference', which is

	short-hash (commit-subject, author-date)

(example:)

	alx@devuan:~/src/shadow/shadow/master$ git log -1 --pretty=reference HEAD
	b55a55aeb (lib/string/: Use QChar_of() to simplify some macros, 2025-11-25)

The kernel format is known to not be good enough, as 12-char-hashes are
known to have collisions.  And the subject isn't enough to disambiguate,
as some commits have quite generic subjects which also have collisions
(e.g., tfix).  Thus, a date helps disambiguate.

The problem with the author dates is that they're not correlative.  You
could have commits applied today that have been authored a few years
ago (consider a slow review process).  Commit dates, instead, are always
correlative (unless you specify a different one with
GIT_COMMITTER_DATE).  When disambiguating, you could look at git-log(1),
do a binary search on the commit date, and then from the few commits of
that day, the hash should be easy to find unambiguously.

I used the quotes, for consistency with the kernel format, and because
it reads better.

About putting the date before instead of after, it has several reasons:

-  Avoid confusion.  If I left the date at the end, one could think I'm
   using --pretty=reference format, and thus think it's an author date.

-  Alignment.  The dates always take the same space XXXX-XX-XX, so
   having them first results in a visually more pleasing format.  Your
   eyes can find both the date and the start of the subject easily,
   without having to parse anything.

-  It allows knowing how old the bug being fixed is, and in which
   release it was introduced (if you know the dates of each release).

And in some cases, the author date might be important, which is why
I sometimes use ref2, but it's an exception.  When I use the author
date, it goes before the commit date, for consistency with how
git-log(1) shows them.

The dates are separated with a comma between then, and then with
a semicolon from the subject.  This makes it even machine parseable.

	alx@devuan:~/src/shadow/shadow/master$ git ref HEAD
	b55a55aebc5d (2025-12-26; "lib/string/: Use QChar_of() to simplify some macros")
	alx@devuan:~/src/shadow/shadow/master$ git ref2 HEAD
	b55a55aebc5d (2025-11-25, 2025-12-26; "lib/string/: Use QChar_of() to simplify some macros")

The full format would be

	12-char-hash ([author-date,] commit-date; "commit-subject")

where [] denotes an optional field.


Have a lovely night!
Alex

> Will send a v2 shortly.
> 
> –Günther

-- 
<https://www.alejandro-colomar.es>

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]