git version 2.20.1
(base) piadmin@pi-spec1:~/pi$ git log
commit 2851703321fd8d026c51621dd9553f2cec92a6c0 (HEAD -> PI_InFactory, tag: PI_shipped_20220310, origin/PI_InFactory)
Author: David <dac@me.ca>
Date: Thu Mar 10 10:08:34 2022 -0500
Fix classes to match PI, on commented line, for agile customer support
(base) piadmin@pi-spec1:~/pi$ git log | more -20
commit 2851703321fd8d026c51621dd9553f2cec92a6c0
Author: David <dac@me.ca>
Date: Thu Mar 10 10:08:34 2022 -0500
Fix classes to match PI, on commented line, for agile customer support
Notice what's missing on the "commit" line when I used "more"?
Clarification edit: When I ask "why", it's because in my decades of linux experience, I've never seen output change (besides loss of colour) when piping something to more. It seems to me like a foundational concept of command line *nix, and the pipe architecture, that this cannot happen, so I guess I mean both "how?" and "why?".
After the answer from @LeonardoDagnino, I see that I should expect this behaviour if I typed git log --decorate=auto, but I am not adding this argument, and the help says the default option should be 'short' anyway.
The manual page git-log(1) (since version 3.33) explains that the default behaviour for --decorate is auto, and what it does changes whether you are running in a terminal or not:
--no-decorate, --decorate[=short|full|auto|no]
<...>
If auto is specified, then if the output is going to a terminal, the ref
names are shown as if short were given, otherwise no ref names are shown.
<...>
Default to configuration value of log.decorate if configured, otherwise,
auto.
When you run a program with a pipe on its output, the output becomes the pipe itself, not a terminal, and as such no ref names are shown.