first line truncated with `git log --oneline --decorate --graph`

I have a bug using the following command:

    git log --oneline --decorate --graph

In short, the first line of the log is often truncated.

If the terminal is too small to display all the text (~100 columns, and too much text to fit on the high of screen, in this example less than 4 lines), I
actually see:

If my history is:

* 4656b73 (HEAD, long_branch_name_and_long_commit_name) Merge commit
'f7f6e4736ad040a1238644a33b681a66c79fac0e' into HEAD
|\
| * f7f6e47 (master) Praesent et diam eget libero egestas mattis sit amet vitae augue.
| * 8dccb9d Maecenas congue ligula ac quam viverra nec consectetur ante hendrerit.
|/
* f7724a2 Lorem ipsum dolor sit amet, consectetur adipiscing elit. Donec a diam lectus.

If my screen is not high enough, I see:

1238644a33b681a66c79fac0e' into HEAD
|\
| * f7f6e47 (master) Praesent et diam eget libero egestas mattis sit amet vitae augue.
| * 8dccb9d Maecenas congue ligula ac quam viverra nec consectetur ante hendrerit.

# next message truncated, because the screen is too small

instead of:
* 4656b73 (HEAD, long_branch_name_and_long_commit_name) Merge commit
'f7f6e4736ad040a1238644a33b681a66c79fac0e' into HEAD
|\
| * f7f6e47 (master) Praesent et diam eget libero egestas mattis sit amet vitae augue.
| * 8dccb9d Maecenas congue ligula ac quam viverra nec consectetur ante hendrerit.

# next message truncated, because the screen is too small

As you can see, the first line is truncated.

If I use:

    git log --pretty=oneline --all --decorate --graph
instead of:
    git log --oneline --all --decorate --graph

the problem is the same (first line truncated).

I have see that bug using terminology or xterm, with bash (without .bashrc) or zsh
(lots of things in my .zshrc), and my desktop environment is i3/archlinux/git
version 2.3.5 It is not a recent regression (if it is, I've learn git one year
ago).

# How to reproduce

Open a small terminal windows (4*100)

mkdir tmp
cd tmp
git init
git commit --allow-empty -m 'Lorem ipsum dolor sit amet, consectetur
adipiscing elit. Donec a diam lectus.'
git checkout -b long_branch_name_and_long_commit_name git commit --allow-empty -m 'Maecenas congue ligula ac quam viverra
nec consectetur ante hendrerit.'
git commit --allow-empty -m 'Praesent et diam eget libero egestas
mattis sit amet vitae augue.'
git checkout master
git merge --no-ff long_branch_name_and_long_commit_name -m 'merge
with a long commit message'
git checkout long_branch_name_and_long_commit_name
git merge master
git log --oneline --decorate --graph

I hope it is clear. The English is not my mother tongue. --
Robin Moussu
//

It is clear and it does not reproduce for me. I see

--------
* 5eff3a3 (HEAD -> long_branch_name_and_long_commit_name, master) merge with a long commit message
|\
| * 61e21f3 Praesent et diam eget libero egestas mattis sit amet vitae augue. :
--------

which looks perfectly sensible (my terminal is a "screen" running on a Ubuntu machine, displaying to a SecureShell terminal on a Chromebook).

Can you try running that problematic "git log" with its standard output redirected to a file (i.e. "git log ... >output") and then run your pager in that wide-but-short terminal (i.e. "less output"), to see if the same problem is observed? And then run "cat output" in a taller terminal with the same width to see if it is the output from "git log" that is causing you the problem?

Hi,

I imagine that the pager (less) cuts off the lines because we start it with the -S option.

Robin, if the pager does not quit right away and you see a truncated line, could you try to press the keys -, Shift+S, <Enter> and see whether they are "untruncated"?

Ciao,
Johannes

Hey folks, please remove git-owner from the CC: list, that goes to me and not the list :-)

Hi David,

I feared as much, but I cannot recall putting you on any Cc: myself. It appeared to me as if the list added git-owner@vger as sender, at least under *some* circumstances...

Ciao,
Dscho

[retaining davem in cc in case he is curious, and hopefully does not
see this as more spam :) ]

Weird. In a nearby thread with the same problem, the first email that mentions git-owner in a cc header is yours[1]. It's in reply to a message that does not mention git-owner at all[2], except in the "Sender" field. Your agent header looks like:

User-Agent: Roundcube Webmail/1.1.0

Maybe their "reply to all" function is a little over-zealous?

Messages from you from a few days ago do not show this problem, but several starting on the 15th do. I don't see anything changing in the messages from the list. Maybe your webmail provider changed something? Or maybe it is a difference between replying to the version that came through the list rather than one that came straight to you.

-Peff

[1,2] Rather than link to an archive, I'll attach full messages as I
received them to make sure the headers are intact.

From: Jeff King <[email protected]>
Date: Thu, 16 Apr 2015 12:26:21 -0400

This is always caused by broken reply list handling in email clients.

That must be it. Dave, my apologies! Will investigate *right now*.

Hi Dave,

With the help of Peff, who identified the culprit (http://trac.roundcube.net/ticket/1489011 introduces this bug, but maintains to fix one), I was able to fix this on my side: https://github.com/dscho/roundcubemail/commit/baec39d

Please accept my sincerest apologies,
Johannes

Hi Junio and Johanes,
It was effectively a less problem, and not a git problem. My $LESS is '-r'. If I make "export LESS='-R' ", it is fixed.

Thanks a lot.
Cheers.
Robin.