[bug] 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 //

Robin Moussu <robin.moussu@gmail.com> writes:

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,

On 2015-04-16 17:28, Junio C Hamano wrote:

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,

On 2015-04-16 17:56, David Miller wrote:

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 :) ]

On Thu, Apr 16, 2015 at 06:11:47PM +0200, Johannes Schindelin wrote:

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 <peff@peff.net>
Date: Thu, 16 Apr 2015 12:26:21 -0400

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

On 2015-04-16 18:31, David Miller wrote:

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

Hi Dave,

On 2015-04-16 19:06, Johannes Schindelin wrote:

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.