Instead of requiring the user to install the right version of the tool in their
.bin folder, create a shim that automatically runs the right version of the
tool. This has several benefits:
- it works out of the box with no setup required (the tool will be automatically
downloaded and compiled the first time it is used)
- no work needed for developers when we bump the golangci-lint version
- it works in working copies that are used in different environments (e.g.
locally on a Mac, or inside a dev container)
Co-authored-by: kyu08 <49891479+kyu08@users.noreply.github.com>
- **PR Description**
Add support for Alt+Backspace (Option+Backspace on macOS) to delete
entire words in text input areas, matching common text editor behavior.
- **PR Description**
This is a small PR that extends the logic added in
https://github.com/jesseduffield/lazygit/pull/4704
There were many reports of users accidentally resetting the working tree
using the reset commands and a nice change was added by @stefanhaller to
prompt for confirmation on those actions but the "Nuke working tree"
option was not covered by the PR.
I believe this one is actually one of the most important options to
prompt because it's by default the first one on the list. I myself
triggered it once when trying to discard a single file while unknowingly
having caps-lock enabled as I thought I was confirming the single file
discard option.
## **PR Description**
I added a new feature to checkout to the last branch.
I think it would be convenient to be able to checkout to the last branch
with just one key stroke(`-`) in some cases, such as when switching
between multiple branches during code review.
Off course, I know that you can same thing by entering `"-"` to the text
input of "Checkout by name" or using custom command but I think `git
checkout -` is occasional use case. So I feel this feature can be a part
of default features.
Another advantage of this feature is that you can checkout to the last
branch regardless of cursor position.
Being able to switch branches without worrying about cursor position
reduces stress I think.
We forgot to convert the model indices to view indices in searchModelCommits.
This needs to be done for search results to be highlighted correctly in the
"divergence from upstream" view, which adds "--- Remote/Local ---" entries, and
during a rebase, where we have "--- Pending rebase todos ---" and "--- Commits
---" which offset view indices from model indices.
I have seen cases where during a rebase (two nonModelItems) all entries in
viewIndicesByModelIndex beyond the second nonModelItem were off by 4 rather than
2 as I would expect. The only explanation I have for this is that the function
was called concurrently.
Improve this by working on a local variable and only assign to self at the end;
this is not a real fix for the concurrency issue of course, but it makes it much
less likely to be a problem in practice.
- **PR Description**
In prompts with a suggestions panel (e.g. the "Execute shell command"
window, or the "Filter by path" panel), you can now
- scroll the list of suggestions with the mouse wheel even when the
focus is in the edit field
- click in the suggestions list or in the edit field to switch focus
between them
- double-click a suggestion to trigger it
This doesn't change behavior, just makes the code a little bit easier to
understand: the outermost condition is "do we show a popup and is the mouse
event for some other view than the focused one". Only if that's true do we need
to define the isCommitMessageView function, and check whether both views belong
to the commit message editor.
- **PR Description**
Previously, any click on an already selected line in a list view was
treated as a double click, and triggered the same action as pressing
either enter or space, depending on the view. Improve this by doing
proper double-click detection based on how much time has passed between
clicks.
Fixes#2526.
Previously a click was detected as a double-click whenever the click was on the
already selected line, regardless of how long ago the last click was (or even
when it wasn't selected by clicking at all). Now that gocui supports proper
double-click detection, we can do better.
The rationale for this is the same as in the previous commit; however, for these
functions we only allow a single controller to set them, because they are event
handlers and it doesn't make sense for multiple controllers to handle them.
Trying to do this would previously have the second one silently overwrite the
first one's.
We don't currently have this in lazygit, but I ran into the situation once
during development, and it can lead to bugs that are hard to diagnose.
Instead of holding a list of functions, we could also have added a panic in case
the function was set already; this would have been good enough for the current
state, and enough to catch mistakes early in the future. However, I decided to
allow multiple controllers to attach these functions, because I can't see a
reason not to.
These are never called on the context, they only exist to satisfy the
HasKeybindings interface. But that's wrong, HasKeybindings has nothing to do
with focus handling or rendering the main view. Remove them from that interface
and add them to IController instead.
Similar to what was done in 457cdce61d, and for the same reason.
However, instead of waiting and fixing them one by one as we see them fail, I
decided to go about it more systematically. To do that, I added calls to
`time.Sleep(1 * time.Second)` in all the Shell.Commit* helper functions; this
ensures that all the commits we make get different committer time stamps, making
all these tests fail. With this I'm pretty confident that we're good now.
When entering filtering we would only call FocusLine, which takes care of
highlighting the selected line in the commits list, but not of re-rendering the
main view. HandleFocus does that.
When exiting filtering, the HandleFocus call was missing entirely.
The tests needed to be reworked a little bit to make this testable.
Now that -committerdate is the default sort order, we could get different
results for the sort order of the branches list depending on whether the commits
on both branches have the same committer time stamp (likely in an integration
test, since git time stamps have second resolution), in which case git will fall
back to alphabetical order, or not (rare, but possible), in which case master
will have the newer commit and will come first. Make this stable by forcing the
sort order to alphabetical.
We might have more tests with this problem, we'll just have to fix them one by
one as we see them fail.
As discussed in #4602, we make a general change to how we treat UI
settings that can be changed from within lazygit; previously, the rule
was to persist them in State.yml so that they automatically remember the
last value that was set in the UI; now, we no longer do this, and
instead provide user configs for setting defaults which we fall back to
on every start.
See #4602 for an in-depth discussion about the pros and cons of either
approach, and why we chose this one.
As part of this, we change the default for the sort order of branches to
date (aka committerdate), both for local and for remote branches (was
recency and alphabetical before, respectively). See the discussion
starting
[here](https://github.com/jesseduffield/lazygit/pull/2147#issuecomment-1656700988)
for some reasons.
Fixes#4602.
At the same time, we change the defaults for both of them to "date" (they were
"recency" and "alphabetical", respectively, before). This is the reason we need
to touch so many integration tests. For some of them I decided to adapt the test
assertions to the changed sort order; for others, I added a SetupConfig step to
set the order back to "recency" so that I don't have to change what the test
does (e.g. how many SelectNextItem() calls are needed to get to a certain
branch).
When toggling the value in the UI we simply overwrite the value in UserConfig;
this would be bad if there was ever a chance that we want to write the user
config back to disk, but it is very unlikely that we can do that, because
currently we have no way to tell which parts of the config come from the global
config file and which ones come from a repo-local one.
