Failed to load repositories. Confirm that selected base ref is valid, then try again.
Loading
base: v0.54.1 head repository: jesseduffield/lazygitFailed to load repositories. Confirm that selected head ref is valid, then try again.
Loading
compare: v0.54.2Stop bumping our homebrew formula
It is being auto-bumped by homebrew, like most formulae these days, so no reason for us to do that explicitly; and it actually fails with an error message, so stop trying.Configuration menu Browse the repository at this point in the history
Stop bumping our homebrew formula (#4799)
It is being auto-bumped by homebrew, like most formulae these days, so no reason for us to do that explicitly; and it actually fails with an error message, so stop trying.Configuration menu Browse the repository at this point in the history
Trim trailing newlines when showing confirmations
When showing a confirmation whose text ended with a line feed, we would make the popup panel one line less tall than it needs to be, so it would show a scroll bar. One example where this occurred is the very first popup that users ever see (the "seriously you rock" message for new users); that's a pretty bad first impression. This happens because our code to suppress trailing newlines in views doesn't work for styled text, and the text in confirmations is bold. This code checks if the last character of the text is a line feed, and in this case it isn't; the escape sequence for turning bold off comes after it. We should really fix this by improving that mechanism, but this would require some tricky logic, so as a quick fix, trim trailing (and leading) linefeeds from the text that we display in a confirmation, before making it bold.Configuration menu Browse the repository at this point in the history
Fix scrollbar in certain popup panels (e.g. the intro message for new…
… users) (#4804) When showing a confirmation whose text ends with a line feed, we would make the popup panel one line less tall than it needs to be, so it would show a scroll bar. One example where this occurred is the very first popup that users ever see (the "seriously you rock" message for new users); that's a pretty bad first impression. This happens because our code to suppress trailing newlines in views doesn't work for styled text, and the text in confirmations is bold. This code checks if the last character of the text is a line feed, and in this case it isn't; the escape sequence for turning bold off comes after it. We should really fix this by improving that mechanism, but this would require some tricky logic, so as a quick fix, trim trailing (and leading) linefeeds from the text that we display in a confirmation, before making it bold.Configuration menu Browse the repository at this point in the history
The old link was broken, it would have to be "Formula/l/lazygit.rb" instead of "Formula/lazygit.rb". However, I don't find it very useful to link to the raw formula file, so I decided to change the link to point to the homebrew web page for lazygit.Configuration menu Browse the repository at this point in the history
It doesn't really seem to make a difference, but this is what I get from shields.io's builder (no idea where the previous .svg extension came from).Configuration menu Browse the repository at this point in the history
Change color of github tag and homebrew badges to blue
Both of these badges have the coloring logic to show stable releases in blue, and prereleases in orange. The criterion for a prerelease is that the major version is 0. Now it is debatable whether we consider lazygit "stable", but I don't feel we are in a preliminary state of the project, working towards the first final 1.0 release, so I feel blue expresses the state of the project better.Configuration menu Browse the repository at this point in the history
Fix delay with flicking through files or commits when git diff is ver…
…y slow One reason why git diff can be very slow is when "diff.algorithm = histogram" is being used. In this case, showing a very long single-file diff can take seconds to load, and you'll see the "loading..." message in the main view until we got the first lines of the diff to show. There's nothing really we can do about this delay; however, when switching to another, shorter file (or commit) while the "loading..." message is still showing, this switch should be instantaneous. And it was before 0.54.0, but we broke this in 0.54.0 with 8d7740a (#4782); now users have to wait for the slow git diff command to output more text before the switch occurs. To fix this, don't block waiting for the process to terminate if we just stopped it.Configuration menu Browse the repository at this point in the history
Improve CPU usage when flicking through large diffs
The previous commit already fixed the user-visible lag, but there's still a problem with multiple background git processes consuming resources calculating diffs that we are never going to show. Improve this by terminating those processes (by sending them a TERM signal). Unfortunately this is only possible on Linux and Mac, so Windows users will have to live with the higher CPU usage. The recommended workaround is to not use "diff.algorithm = histogram".Configuration menu Browse the repository at this point in the history
Fix delay with flicking through files or commits when git diff is ver…
…y slow (#4803) One reason why git diff can be very slow is when "diff.algorithm = histogram" is being used. In this case, showing a very long single-file diff can take seconds to load, and you'll see the "loading..." message in the main view until we got the first lines of the diff to show. There's nothing really we can do about this delay; however, when switching to another, shorter file (or commit) while the "loading..." message is still showing, this switch should be instantaneous. And it was before 0.54.0, but we broke this in 0.54.0 with 8d7740a (#4782); now users have to wait for the slow git diff command to output more text before the switch occurs. To fix this, don't block waiting for the process to terminate if we just stopped it. In addition, improve CPU usage by terminating git processes gracefully (by sending them a TERM signal); this helps keep CPU usage low when flicking through several of these huge diffs with "diff.algorithm = histogram", because it avoids having several git processes running in the background, calculating expensive diffs that we are never going to show. Unfortunately this is only possible on Linux and Mac, so Windows users will have to live with the higher CPU usage. The recommended workaround is to not use "diff.algorithm = histogram". Fixes #4798.Configuration menu Browse the repository at this point in the history
Loading
This comparison is taking too long to generate.Unfortunately it looks like we can’t render this comparison for you right now. It might be too big, or there might be something weird with your repository.
You can try running this command locally to see the comparison on your machine: git diff v0.54.1...v0.54.2
You can’t perform that action at this time.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4