Hi all,

When I push content to GitLab, the remote server sends back some text which git then prints to stderr:

  remote:
  remote: To create a merge request for zk, visit:
  remote:   https://gitlab.alpinelinux.org/WhyNotHugo/aports/-/merge_requests/new?merge_request%5Bsource_branch%5D=zk
  remote:

When the width of a whole line is the same as my terminal width, the last digit gets trimmed off. E.g.: if I resize my terminal for the above to fix exactly, and re-run the same command, git prints:

  remote:   https://gitlab.alpinelinux.org/WhyNotHugo/aports/-/merge_requests/new?merge_request%5Bsource_branch%5D=z

From what I can tell, sideband.c prints ANSI_SUFFIX = "\033[K", this escape sequence being "clear the line from the current position until the end of the line", and this is the root cause of the issue.

When piping to cat or to a file, this sequence is not printed, so the output is fine.

Is this a bug?

Thanks,

PS: please CC me, as I am not subscribed to the list.

On Mon, May 4, 2026 at 10:02 AM Hugo Osvaldo Barrera <hugo@whynothugo.nl> wrote: [snippage]

[snippage]

Interesting.

In Ye Olden Dayes of (n)curses, there was (and still is) a terminal capacity boolean flag, "xn" or (in terminfo which is more verbose) "xenl", the "terminal eats newline glitch".

Consider your bog-standard 80x24 "glass tty" from the late 1970s / early 1980s. Printing a line of exactly 80 characters caused the cursor to march from column 1, to 2, to 3, ..., to 80, to ... column 81? There is no column 81. So what is this "glass tty" to do?

Some acted like a print head, leaving the cursor stuck in column 80, so that printing *more* characters just made that big black blob of ink on the paper er I mean erased each previous character with the new one printed on top. So then a final "new line" sequence left the cursor on column 1 of the next line, which is where we want it.

Some thought this was annoying and/or stupid so they immediately wrapped to column 1 of the next line, as if the computer had sent a newline sequence. But if the line was in fact exactly 80 characters, this meant the subsequent newline sequence moved to column 1 of the *next* row, leaving a blank line (or scrolling the screen twice or whatever). This is Obviously Bad Behavior, but the "overprint" answer is equally Obviously Bad.

There were two ways of dealing with the problem intelligently: put the cursor to an internal "column 81" that, if there's a newline, sends the cursor to column 1 of the next row; or simply set a flag and eat the next character if it's a newline. (This is a little trickier than it sounds since the newline sequence is actually CR+LF, or LF+CR, depending on certain computer-maker choices, but it works either way.)

The xn / xenl flag describes terminals that behave this way. The screen-oriented programs (ex/vi, now vim and emacs and nano and so on, plus things like "more"/"less"/other pagers, etc) would know to send an extra newline here if the xn/xenl flag is true, and not if not since the cursor was already on column 1 of the next line automatically. (Though actually this depends on another boolean, "am", auto-right-margin. Lacking "am", the cursor simply hammers on the final column, the overprint Bad Behavior Mode.)

Alas, this does not describe what happens if one sends the "clear to end of line" sequence. If the cursor is in the phantom "column 81", perhaps that sequence does nothing. If it's lingering in column 80, perhaps that clears the character under the cursor. All that xn tells you is "send a newline anyway".

As for what to do, well, that could be tricky. Git *could* check for "am" and "xn" / "xenl", but that requires parsing termcap/terminfo, which is kind of a nightmare. It also requires counting cursor column movements, which is something of a mug's game.[1] If you're willing to play that game though, you could just count and, if at the last column as determined by "tty column width" inquiry, omit the ESC [ K entirely: there's nothing to clear. If you have a non-empty prefix string before this "clear to end of line" suffix, the solution is more obvious: print the ESC [ K as a *prefix* rather than a suffix, but that fails with the empty prefix.

One last easy possibility is to print an extra space before the ESC [ K. It's imperfect, as it causes a blank line for these exact-width lines, but avoids data loss.

Chris

[1]: https://www.merriam-webster.com/dictionary/mug%27s%20game

On Mon, May 4, 2026 at 7:02 PM Hugo Osvaldo Barrera <hugo@whynothugo.nl> wrote:

grep has the same bug with --color, if you have a line of text the same width as your terminal, for the same reason. urxvt supports an extension of \e[3K to clear to end but not erase the character under the cursor if it's wrapped (but not yet moved to the next line). xterm hasn't picked it up though, so it's not a general solution, unfortunately. It's a little unclear to me why git prints this sequence here at all, are we expecting that there is already other text printed on the line? Or is it to clear cells that may have had another background color when the current line was scrolled in? Maybe that case is more unusual and less harmful than actually eating the final character, that it's not worth clearing?

On 5/5/26 2:34 AM, Chris Torek wrote:

We do have a non-empty prefix, but why would it be necessary? What's wrong with clearing the full line starting from column 1?

Anyway, do you mean something like this?

On Tue, May 5, 2026 at 9:46 PM René Scharfe <l.s.r@web.de> wrote:

If the purpose of the clear is to reset the background color on wrapped lines, this will not have any effect, since you clear before the new line is wrapped in. (This is a bit of an obscure edge case, if you set the background color, and wrap the line, the entire new line will be scrolled in with the active background color, then you write perhaps 10 more characters and send the sequence to reset the background color, but the entire rest of the line is still brown, or whatever it was set to when you wrapped).

Example command to reproduce locally, % echo -e '\e[43maaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa\e[0mhihi' (Add more aaaaaaa if necessary so that the line breaks before they end).

On Wed, May 6, 2026 at 11:37 AM Mikael Magnusson <mikachu@gmail.com> wrote:

Sorry for the double post, but I forgot an important thing, this only happens if you *actually* scroll in a new line, ie if you open a new terminal and run this, you won't see any problems until you get to the bottom of the screen.

On 5/6/26 11:40 AM, Mikael Magnusson wrote:

The purpose of clearing here is to avoid leaving local progress line remnants after the remote line. Original discussion: https://lore.kernel.org/git/alpine.LFD.0.9999.0711032328490.21255@xanadu.home/

You're right that erasing before filling the whole line and then some is unnecessary. But it wouldn't hurt, either, no?

René

demultiplex_sideband() can write its remote output over active local progress lines. That's why it has been using ANSI code Erase in Line on smart terminals to clear the remainder of lines it writes since ebe8fa738d (fix display overlap between remote and local progress, 2007-11-04).

This erases the last character of remote lines that span the full width of the terminal, though, as the cursor is stuck at the rightmost column for them. It's the same effect as in the following command, which clears the 1 and shows just the leading zeros:

   $ EL="\033[K"
   $ printf "%0${COLUMNS}d${EL}\n" 1

If we move the ANSI code to the start we get to see the 1 as well:

   $ printf "${EL}%0${COLUMNS}d\n" 1

So do the same in demultiplex_sideband() and emit the ANSI code as a prefix instead of a suffix to show messages in full even if they happen to fill the whole width of a smart terminal.

Reported-by: Hugo Osvaldo Barrera <hugo@whynothugo.nl>
Suggested-by: Chris Torek <chris.torek@gmail.com>
Signed-off-by: René Scharfe <l.s.r@web.de>
---
 sideband.c | 22 ++++++++++++----------
 1 file changed, 12 insertions(+), 10 deletions(-)

René Scharfe <l.s.r@web.de> writes:

Makes sense. The final objective is to make sure that leftover letters near the end of line printed by previous "print" would not remain after the material we are printing, so it does not matter if we print and then erase the remainder or we erase the whole line and print. And the latter is an obvious way to make it easier to reason about in the presense of funkiness in the ways terminals behave around the end of line.

"Hugo Osvaldo Barrera" <hugo@whynothugo.nl> writes:

Please tell us more, if you are running Git 2.55 (or newer) and seeing the above behaviour.

It updated in 31e8fcabd8 (sideband: clear full line when printing remote messages, 2026-05-10) and was shipped in Git 2.55 on 2026-06-29.