### PR Description
Way back when I implemented filter functionality I could not muster the
motivation to apply it to the file views (files and commit files), but
it really should be used on them.
The text filter matches against the full file path (not just the
filename), which is more useful for navigating large directory trees.
When a text filter is active, all operations respect it consistently:
- **Diffs**: selecting a filtered directory shows only the diff of
visible files, not all files in the directory
- **Staging/unstaging**: pressing space on a filtered directory only
stages/unstages visible files
- **Toggle all (a)**: only toggles staging for visible files
- **Custom patch**: toggling a filtered directory only adds visible
files to the patch
Full disclosure, opus 4.6 wrote this entire PR but reviewing its changes
they seem reasonable, and I have done some local testing and everything
works as expected.
Change working tree files and commit files panels to use filtering
(reducing the list) instead of search (highlighting matches). This
matches the behavior of other filterable views.
The text filter matches against the full file path, not just the
filename, which is more useful for navigating large directory trees.
When toggling a directory for a custom patch while a text filter is
active, only the visible filtered files in the directory are affected,
consistent with how staging a directory in the files panel works.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Without this check, the selection was being reset to 0 whenever
ReApplyFilter was called for the current filter context, even when
the user wasn't actively typing in the search prompt (e.g. when the
model updates in the background). This was causing unexpected cursor
jumps.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
When opening a filter prompt, reset PrevSearchIndex to -1 to avoid
stale search state from a previous search/filter session.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
This avoids a naming collision with GetFilter from the
IFilterableContext interface, which will be implemented by
FileTreeViewModel in the next commit.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
I always press 'd' in the patch building view, expecting that I can do
exactly what I can do in the staging view, to find out I need to go
space -> ctrl+p -> d and I think it's time to honour the muscle memory
and support this convenience keybinding. I recall we may have had a
debate about this in the past and if so I'm renewing my stance.
I always press 'd' in the patch building view, expecting that I can do
exactly what I can do in the staging view, to find out I need to go
space -> ctrl+p -> d and I think it's time to honour the muscle memory
and support this convenience keybinding.
We don't add the commands to the menu when we're rebasing, so it's pointless to
check this in the handlers.
I guess alternatively we could add all commands always, and strike out the ones
that are not applicable using DisabledReasons. But we don't usually do this in
menus (except the global keybindings menu).
Only mention resetting the patch when there actually is one. This way users have
to read less text in the normal case, and the added note hopefully stands out
more if there is one. Also, separate the note from the previous text by a blank
line.
"Remove" can be confusing when a deleted file is selected; in this cases it
actually "un-removes" it. "Discard" hopefully makes it clearer that we are
talking about the change to a file, and not the file itself.
If the bottom line is hidden (by setting `gui.showBottomLine` to false
in the config), don't show the "Fetching..." status because it changes
the layout, which should happen only in response to user actions.
However, keep the status for the first fetch after startup, and right
after switching repos, because in these cases it is useful to see when
the fetch is done.
Closes#5242.
If the bottom line is hidden (by setting gui.showBottomLine to false in the
config), don't show the "Fetching..." status because it changes the layout,
which should happen only in response to user actions.
However, keep the status for the first fetch after startup, and right after
switching repos, because in these cases it is useful to see when the fetch is
done.
### PR Description
Tweak regexp such that a trailing ":" is not included in the file path
extracted from a lazygit-edit URL.
Previously, when matching a URL containing the ":" separator but no line
number, such as `lazygit-edit:///path/to/file.ext:`, the trailing
separator would be included in the matched file path, so lazygit would
open the non-existent file `/path/to/file.ext:`. Notably, such urls are
created when using delta with the hyperlink feature, as suggested in
https://github.com/jesseduffield/lazygit/blob/master/docs/Custom_Pagers.md#delta,
and clicking a file path rather than a line number.
Fixes#5308
Tweak regexp such that a trailing ":" is not included in the file path
extracted from a lazygit-edit URL.
Previously, when matching a URL containing the ":" separator but no line
number, such as `lazygit-edit:///path/to/file.ext:`, the trailing
separator would be included in the matched file path, so lazygit would
open the non-existent file `/path/to/file.ext:`. Notably, such urls are
created when using delta with the hyperlink feature, as suggested in
https://github.com/jesseduffield/lazygit/blob/master/docs/Custom_Pagers.md#delta,
and clicking a file path rather than a line number.
There's too much manual work involved in releasing now (updating
translations, copying docs-master) to make automatic releases
infeasible. I'm not worried that I forget to release on the first
Saturday of every month.
Keeping the code commented out in case we want to re-enable it at some
point.
There's too much manual work involved in releasing now (updating translations,
copying docs-master) to make automatic releases infeasible. I'm not worried that
I forget to release on the first Saturday of every month.
Keeping the code commented out in case we want to re-enable it at some point.
This is a regression introduced with #5135. I didn't notice it because I
am using `gui.scrollOffBehavior: jump`, in which case the problem
wouldn't appear; it only happened with `scrollOffBehavior: margin`
(which is the default). In that case, if you used the arrow keys (or
j/k) to move the selection so that the view would start to scroll, empty
space would appear.
Fixes#5235.
This is a regression introduced with #5135. I didn't notice it because I am
using `gui.scrollOffBehavior: jump`, in which case the problem wouldn't appear;
it only happened with `scrollOffBehavior: margin` (which is the default). In
that case, if you used the arrow keys (or j/k) to move the selection so that the
view would start to scroll, empty space would appear.
### PR Description
Paths added to ignore/exclude files need to be prefixed with a forward
slash to point to a specific file in the directory tree.
Without that prefix a file at root called `file` (added to `.gitignore`
as `file`) would match with `./file` and `./src/file`.
Example flow:
1. User creates a directory called `tests` in root
2. User sees that it's tracked
3. User ignores the directory in Lazygit
4. Changes in `src/tests` are now missing - because `tests` without `/`
matches also directories lower in the tree
Paths added to ignore/exclude files need to be prefixed with a forward
slash to point to a specific file in the directory tree.
Without that prefix a file at root called `file` (added to `.gitignore`
as `file`) would match with `./file` and `./src/file`.
This brings in https://github.com/jesseduffield/gocui/pull/98 with the following
fix:
Fix rendering of CRLF sequence ('\r\n')
The FirstGraphemeCluster call returns this as a single character; we want to
treat it the same way as a single \n.
This would be a problem if e.g. a progress bar used \r repeatedly to paint over
the same line, and then printed a \n to move on to the next line; the last pair
of \r and \n was swallowed.
Another scenario where this was a problem was if you stream output of a command
to the log, and the command used \r\n as line feeds. This happens for example
for a background fetch that fails with an error; in that case we print the
combined output (stdout plus stderr) to the log after the command finished, and
for some reason it uses \r\n in that case (I can't actually explain why; when I
do `git fetch --all | xxd` I see only bare \n characters). All output would
appear on one line then.
Also, filter out escape sequences for character set designation; there's nothing
useful we can do with them. In practice, the only one that you are likely to see
is `ESC ( B`, which is sent as part of tput sgr0, which is sometimes used in
scripts to reset all graphics attributes to defaults.
### PR Description
I had a spare couple hours so figured I'd whip up a PR for a feature
I've wanted for a while.
I've optimised for muscle memory backwards compatibility here:
- Outside interactive rebase: press 'f' then instead of a confirmation
panel, a menu appears where you can choose to keep the selected commit's
message
- Inside interactive rebase: press 'f' then press 'c' to see the menu
for keeping the message, where if you press 'c' again it will retain the
current message. so 'fcc' is the chord to press.
We're also now showing the -C flag (which is what enables the behaviour)
against the todo.
I've picked the 'c' keybinding because 'C' was taken and it corresponds
to the flag. Previously that showed a warning about a change in
keybinding for cherry picking but it's been ages since we've made that
change so I'm happy to retire it.
I've optimised for muscle memory backwards compatibility here:
- Outside interactive rebase: press 'f' then instead of a confirmation
panel, a menu appears where you can choose to keep the selected commit's
message
- Inside interactive rebase: press 'f' then press 'c' to see the menu
for keeping the message, where if you press 'c' again it will retain the
current message. so 'fcc' is the chord to press.
We're also now showing the -C flag (which is what enables the behaviour)
against the todo.
I've picked the 'c' keybinding because 'C' was taken and it corresponds
to the flag. Previously that showed a warning about a change in
keybinding for cherry picking but it's been ages since we've made that
change so I'm happy to retire it.
Not used yet, we pass an empty string everywhere, to match the previous
behavior. Just extracting this into a separate commit to make the next one
smaller.
Co-authored-by: Stefan Haller <stefan@haller-berlin.de>
It's been ages since we changed the key, users should hopefully be used to it by
now, and we want to reuse the key for something else later in the branch.
Co-authored-by: Stefan Haller <stefan@haller-berlin.de>
On very large screens they would get ridiculously wide.
The limits we chose here are a little arbitrary:
- 80 for confirmations and prompts
- 90 for menus
- auto-wrap width plus 25 for the commit message editor (or 100 if
auto-wrap is off)
On very large screens they would get ridiculously wide.
The limits we chose here are a little arbitrary:
- 80 for confirmations and prompts
- 90 for menus
- auto-wrap width plus 25 for the commit message editor (or 100 if auto-wrap is
off)
To reproduce: open the keybindings menu ('?'), press '>' to select the
last line, esc to close it, open it again. The view would appear still
scrolled down, so the selected first line was out of view. Even worse,
if you open a different, shorter menu (e.g. the "View upstream reset
options..." menu in the Files panel), you'd only see the Cancel item,
the other ones were scrolled out of view.
This is a regression introduced with efd4298b5e (#5134).
Stefan HallerandGitHub
Daniel WennbergandStefan Haller
Owen ZimmermanandStefan Haller
baiyei_dkandStefan Haller
cadamsdevandStefan Haller
Dawid PietrykowskiandStefan Haller