`git log` breaks echo on terminal (urxvt)

[fernandocanizo]

Great tool! :) However it's also used to display git log, and when I do that on my urxvt terminal, which also uses gbt, I get a broken terminal:

• no echo
• pressing ENTER on an empty command line doesn't advance the prompt (it seems it's sending only a CR character without the LF one)

Probably both things are caused by the same issue.
I have to reset my terminal after each git log, which makes this beautiful tool unusable.

Tried removing the -X | --no-init parameter for less, but the problem persists. So I left it configured as README says:

$ git config --global --get core.pager
git-split-diffs --color | less -RFX

UPDATE: forgot to mention that the terminal doesn't break on git diff, so maybe that's a hint to solve the problem. Obviously git diff does something different than git log.

[banga]

Ah I've run into something like this very occasionally on iTerm2/xterm but haven't been able to repro consistently enough to find a fix. For me, it only occurs when I've been making local changes for a while and then I run git diff for the first time. It stops reproing if I run git diff again. I also don't get the other issues about having to reset my terminal. So maybe they are not the same issue, but I suspect that they are (and I suspect it has to do with an ANSI color sequence being broken up by less or something)

It sounds like you have a consistent repro, do you mind explaining your setup in more detail? And maybe trying a more minimal repro if that's easy? That is, eliminate things like gbt from your bashrc, zshrc and git config and see if it still repros?

[fernandocanizo]

Tried to reproduce it with a minimal setup and I couldn't.

In the process I discovered that I cannot reproduce it on a brand new repository neither on some others I got, but it still breaks on the repository that lead me to file this issue (https://github.com/fernandocanizo/my-env), even if I remove it and re-clone it.

So I guess you can close this. I'll keep investigating why breaks on my repo and will post if I find the problem.

[banga]

Oh I see, thanks. If I can repro consistently that would actually be really useful, so I'll keep this open. Does it break when you show this particular diff: fernandocanizo/my-env@4434b10. Or is it just anything in that repo?

[fernandocanizo]

No, I checkout on a couple of old commits and it still breaks. I have a witched repo :P

[NorthWindH]

I'm consistently seeing this issue as well on windows terminal running bash on ubuntu WSL2. I think I can make a consistent repro; I'll ping back here with the repro when I get it set up.

[banga]

Great, thanks. Please do!

[morokhovets]

Hey, guys!

Let me chime in on this issue.
I was experiencing same issue on my repos on and off but it looked pretty randomly, one time it breaks, next it is not.

What I've found:
I'm not sure what mechanics in Less it is but git-log/git-show/git-diff all use Less in such manner that it does not load all log at once if log is large enough. For me it loads only 59 lines of log rightaway (press ctrl-G to see buffer size).
If you force Less to load it all going to the very end of the log (pressing shift-G), then exiting Less will keep terminal ok.
But if log was not loaded completely into Less buffer then exiting it will break the terminal.

I guess it has something to do with unclosed pipe from git-log to less? But I'm not sure what mechanism is used to 'pause' the pipe if log is large. Any ideas?

[levitsky]

I'm having the same issue in Yakuake and Konsole with bash. I can confirm that the issue occurs after I run git log with a (relatively) long history and then press q to quit. The issue does not occur if I go to the end of the log (G) before I close it.

[trurle]

This happens to me on FC41, in Gnome terminal, when I do git show (and I have long diffs) and exit with q. I think I also saw it happen with git log, again lots of commits. If I page to the end or use G in the pager, it doesn't happen.

less 668 (POSIX regular expressions)