When switching to a different repo, and then back to the original one,
searching would no longer work. The reason is that our contexts set
callbacks on their views; when switching to a different repo we
instantiate a new set of contexts, so they will overwrite the views'
callbacks with their new ones, but when switching back to the original
repo, we reuse the old contexts because they are still in memory, but
they won't set their callbacks again since they only do this on
construction.
To fix this, replace the view-local callbacks with a global one on the
gui that takes the view as an argument, so that the callback can look up
the associated context dynamically.
When switching to a different repo, and then back to the original one, searching
would no longer work. The reason is that our contexts set callbacks on their
views; when switching to a different repo we instantiate a new set of contexts,
so they will overwrite the views' callbacks with their new ones, but when
switching back to the original repo, we reuse the old contexts because they are
still in memory, but they won't set their callbacks again since they only do
this on construction.
To fix this, replace the view-local callbacks with a global one on the gui that
takes the view as an argument, so that the callback can look up the associated
context dynamically.
Remove our dependency on go-git, which was including a ton of
third-party code for very little benefit.
In addition, this fixes the problem that lazygit wouldn't show any
branches or remotes for certain types of malformatted .git/config files,
e.g. when there's a config section like `[branch ""]`, `[remote ""]`, or
`[-remote "xyz"]`; see #3901 and #5112.
### PR Description
This PR adds support for clicking on arrows in the file changes list
view, so that a mouse can be used to expand/collapse directories. This
enhancement was raised here as issue #5088.
Can be used for doing additional click handling in list views.
Like the GetOnDoubleClick hook we should try to find a better design for this
than putting it in HasKeybindings and BaseContext, since it is only used by list
contexts.
Co-authored-by: Stefan Haller <stefan@haller-berlin.de>
We have some documentation for the corresponding setters in IBaseContext, but
that's part of the controller infrastructure and not client facing. For somebody
implementing a new view, this is where they will probably look for what methods
they can override.
When this was originally introduced, it handled single clicks on a list entry
(treating them similar to a double-click by checking whether the click was on
the selected entry). Arguably it should have been called OnDoubleClick back then
already; but when we later changed it to do actual double-click detection (see
37197b8e9a), we should have renamed the methods.
If the showDivergenceFromBaseBranch config is not none, the expanded
branches panel would no longer show the remote branch and subject; the
reason was that we padded the name all the way to the right edge of the
view so that the divergence information is right-aligned.
To fix this, we simply don't right-align the divergence in half or full
screen mode. This is a bit unfortunate, but it's hard to do any better,
because we don't know the width of our column in advance. One thing I
tried is to make the divergence a separate column in that case (with an
explicit right-alignment set on it via getColumnAlignments; however,
this makes it harder to properly truncate the name when the window is
too narrow.
If the showDivergenceFromBaseBranch config is not none, the expanded branches
panel would no longer show the remote branch and subject; the reason was that we
padded the name all the way to the right edge of the view so that the divergence
information is right-aligned.
To fix this, we simply don't right-align the divergence in half or full screen
mode. This is a bit unfortunate, but it's hard to do any better, because we
don't know the width of our column in advance. One thing I tried is to make the
divergence a separate column in that case (with an explicit right-alignment set
on it via getColumnAlignments; however, this makes it harder to properly
truncate the name when the window is too narrow.
Given a block of consecutive changed lines, staging only some of those
changes didn't always work. Consider the following scenario:
```diff
@@ -1,5 +1,5 @@
a
-b
-c
-d
+b'
+c'
+d'
e
```
Trying to stage only the change to "d" worked already as expected, but
staging either "b" or "c" didn't; the order of the deleted and added
lines in staged changes were wrong. We don't solve the "c" case in this
PR, as it's probably uncommon enough so that it doesn't matter too much,
and it seems to be quite a bit harder than the other two (and git gui
doesn't support it either, for the record). But we fix the "b" case
here, which is probably the most common one.
Fixes#5103.
This fixes the problem; a consequence of this change is that given the following
scenario:
@@ -1,3 +1,3 @@
1
-2
+2b
3
staging only the line `+2b` will put it *before* the unchanged `2` line, rather
than after it as you might expect (the changed unit tests demonstrate this).
Since this should be a pretty uncommon scenario, I guess it is an ok compromise.
As you can see in the changed tests, while the behavior of what gets staged is
fixed now, it doesn't always correctly select the next line to stage. We'll
address this in the next commit.
This is a pretty special case (see comment in the test for details). It is
working correctly, but I almost broke it during development, so it's good to
cover it with a test.
Given a block of consecutive changed lines, trying to stage only some of them
doesn't work correctly in all cases:
- if the staged lines are the last lines in the block of changes, it already
works
- when staging some changes in the middle of the block, it doesn't work as
desired, but we also don't try to fix this case in this branch, because it's
harder to do, and not as common as the other two
- staging the first lines of the block doesn't work as desired, and we will fix
that in this branch.
### PR Description
When a branch is checked out by another worktree, show the worktree name
in the label, e.g. "(worktree cosmos2)" instead of just "(worktree)", so
you can immediately see which worktree holds it.
When a branch is checked out by another worktree, show the worktree
name in the label, e.g. "(worktree cosmos2)" instead of just
"(worktree)", so you can immediately see which worktree holds it.
When looking at a diff in diffing mode in the branches or tags panels
(e.g. after pressing `W` on a branch and then selecting a different
branch to diff it against the first one) it wasn't possible to change
the diff context size using `{` and `}`, or the rename threshold using
`(` and `)`.
Fixes#5254.
Actually, we simply enable them in any panel, even those that can never show a
diff. Since the commands show a toast, that's enough feedback to understand what
happened; the change will take effect the next time you switch to a panel that
does show diffs.
Same for ( and ) to change the rename threshold.
We did already have code to prevent clicks in inactive views behind a
popup, but it wasn't good enough. This PR fixes two problems:
- if the previously focused view (behind the panel) was a list view, it
would look like the click would select a different row, because gocui
would still set the view's cursor position, which is used to draw the
highlighted row
- it was still possible to click on tab headers, and this would dismiss
the panel
Fixes#5256.
This fixes two problems:
- if the previously focused view (behind the panel) was a list view, it would
look like the click would select a different row, because gocui would still
set the view's cursor position, which is used to draw the highlighted row
- it was still possible to click on tab headers, and this would dismiss the
panel
The symptom of the bug was that confirmation panels with wrapped text
were one character too wide, which could sometimes result in them being
one line too heigh. One concrete example is the "Discard file changes"
confirmation that appears when pressing `d` in the commit files panel.
I got confused when I investigated the bug that was fixed in the previous
commit, so hopefully these will be helpful for the next person reading this
code.
The symptom of the bug was that confirmation panels with wrapped text were one
character too wide, which could sometimes result in them being one line too
heigh. One concrete example is the "Discard file changes" confirmation that
appears when pressing `d` in the commit files panel.
I got very confused when investigating this bug, and the reason is that
getPopupPanelDimensionsAux took two parameters panelWidth and panelHeight, but
the second was actually contentHeight. Rename it to contentHeight, and change
the first one to also be the content width rather than the panel width. This is
easier for clients, and less confusing.
This commit implements the ability to cycle backward through different
all branches log visualization modes, complementing the existing forward
cycling functionality. Users can now press 'A' (Shift+a) to cycle in
reverse through the available log graph views, improving navigation
efficiency when they overshoot their desired view.
This commit implements the ability to cycle backward through different
all branches log visualization modes, complementing the existing forward
cycling functionality. Users can now press 'A' (Shift+a) to cycle in
reverse through the available log graph views, improving navigation
efficiency when they overshoot their desired view.
Changes:
- Added RotateAllBranchesLogIdxBackward() method to BranchCommands for
backward rotation through log command candidates
- Introduced AllBranchesLogGraphReverse keybinding configuration with
default key 'A' (uppercase)
- Implemented switchToOrRotateAllBranchesLogsBackward() handler in
StatusController that mirrors forward cycling logic
- Added English translation for "Show/cycle all branch logs (reverse)"
The implementation uses modulo arithmetic with proper handling of
negative indices to ensure seamless backward cycling through the
available log visualization options.
Fixes#5302
## Problem
When `.git/info` directory does not exist (can happen with bare clones,
manual deletion, or certain Git configurations), selecting "Add to
.git/info/exclude" fails with:
```
open <repo-path>/.git/info/exclude: no such file or directory
```
The `Exclude` function used `os.OpenFile` with `os.O_CREATE` which
creates the file but not its parent directory.
## Fix
Added `os.MkdirAll` to create the `.git/info` directory (with 0755
permissions) before attempting to open the exclude file. `MkdirAll` is a
no-op if the directory already exists, so existing behavior is
unchanged.
## Test
Added integration test `file/exclude_without_info_dir` that:
1. Removes `.git/info` directory during repo setup
2. Attempts to exclude a file via the menu
3. Verifies `.git/info/exclude` is created with the correct content
Test fails without the fix, passes with it.
Tested locally on macOS ARM (Apple Silicon). Unit tests and integration
test pass.
Stefan Haller
blakemckeany
Ruud Kamphuis
github-actions[bot]
Zak Siddiqui
04cb