Can you give some more details about what steps you are taking to produce this? Particularly if you have configured a non-default pager.

Here is me prior to pressing a:

and after pressing a

which is expected behavior. I can then click <space> to confirm that I want to stage that hunk.

I use delta, in my config: pager: delta --paging=never --line-numbers --hyperlinks --hyperlinks-file-link-format="lazygit-edit://{path}:{line}"

The hunk is selected, but partial like:

I've seen this too. I think it happens for longer hunks, where the view needs to scroll so that the end of the hunk becomes visible. As far as I remember, this is only a visual problem, pressing space to stage the hunk should still work fine (not 100% sure on that).

I'll have a closer look when I find some time.

I can confirm I see the same behavior. Indeed it seems to only be a visual bug for longer hunks, but staging still works fine. However, it is sometimes difficult to understand what will be considered as a hunk and what not due to this.

I imagine this has nothing to do with the custom pager since it is currently not used in the staging mode, but just in case, I am also using delta as the custom pager.

this is happening for me. I have delta configured for git. but not for lazygit

I can confirm this bug happens even with NO configuration at all. Tested on macOS with lazygit v0.45.2.

Test setup:

• Removed lazygit config entirely (no ~/.config/lazygit/config.yml)
• Disabled git pager (git config --global core.pager "")
• Disabled interactive.diffFilter

Results:

• numbers.txt with non-contiguous changes: 'a' selects entire file instead of hunk

• app.js with long functions: Visual selection highlight glitch

But all gets staged upon pressing space

• test_hunk.py Visual selection highlight glitch,

But this time stages fine.

So this is definitely a core lazygit bug, not related to delta or any user configuration. The bug manifests differently depending on the file content and hunk structure.

Thanks for the elaborate report Adrian, but we have a fix for this already (#4589), it just hasn't been merged yet. Please test it if you can build from source.

And btw, 0.45 is really old, do yourself a favor and update to the latest version. You are missing out on a ton of new enhancements and fixes.

And btw, 0.45 is really old, do yourself a favor and update to the latest version. You are missing out on a ton of new enhancements and fixes.

Oh, I wasn't aware! Thanks for letting me know.

it just hasn't been merged yet

ETA?

ETA?

This was closed based on the merging of the PR, so it'll be included in the next release! (Which happens monthly, unless we decide to deploy a hotfix version)

Side note... I wish GitHub would make key events like this more noticeable, I know I've missed them plenty of times!

Side note... I wish GitHub would make key events like this more noticeable, I know I've missed them plenty of times!

You can quite literally select to be notified about releases only, however, I wouldn't want to clutter my email for this.

Ideally, Lazygit should notify about new versions every once in a while or at startup, this should be default but potentially option to calm for the tinfoil club :)

Should I make this a feature request @stefanhaller

Ideally, Lazygit should notify about new versions every once in a while or at startup, this should be default but potentially option to calm for the tinfoil club :)

Should I make this a feature request @stefanhaller

A feature request is not needed for this, lazygit does have check-for-update functionality built in already. If anything, it would be an enhancement request to make it work better. I have never cared much about how it works, and why it doesn't seem to do anything in some situations. Some relevant code is here if you feel like researching that.

A feature request is not needed for this, lazygit does have check-for-update functionality built in already. If anything, it would be an enhancement request to make it work better. I have never cared much about how it works, and why it doesn't seem to do anything in some situations. Some relevant code is here if you feel like researching that.

I had a closer look just now; our update checks work only for builds that you installed from a tarball downloaded from our releases page. It does nothing if you installed from a package manager. This makes sense because the update mechanism's main goal seems to be updating, not notifying, and you don't want it to try to overwrite the binary in /opt/homebrew for example.

I think it could make sense to extend the mechanism to show a notification if the binary was not installed from our tarball, but a newer version is available. Your package manager might not have a newer version than the one you are using, but you might decide to install the newer version manually, so it's all about wording the notification so it's the most helpful.

Not going to work on this myself any time soon, as I don't care enough right now.