Sadly, as of less-530, the behavior of "less -F" is broken enough that
I think git needs to potentially think about changing the defaults for
the pager, or people should at least be aware of it.
Older versions of less (at least up to less-487 - March 2017) do not
have this bug. There were apparently 520, 527 and 529 releases in
2017 too, but I couldn't find their sources to verify if they were
already broken - but 530 (February 2018) has the problem.
The breakage is easy to see without git:
(echo "hello"; sleep 5; echo "bye bye") | less -F
which will result in no output at all for five seconds, and then you
get both lines at once as "less" exits.
It's not always obvious when using git, because when the terminal
fills up, less also starts outputting, but the default options with -F
are really horrible if you are looking for something uncommon, and
"git log" doesn't respond at all.
On the kernel tree, this is easy to see with something like
git log --oneline --grep="The most important one is the mpt3sas fix"
which takes a bit over 7 seconds before it shows the commit I was looking for.
In contrast, if you do
LESS=-RX git log --oneline --grep="The most important one is the mpt3sas fix"
that (recent) commit is found and shown immediately. It still takes 7s
for git to go through all history and decide "that was it", but at
least you don't need to wait for the intermediate results.
I've reported it as a bug in less, but I'm not sure what the reaction
will be, the less releases seem to be very random.
Linus
