Currently lazygit looks for its config file in `XDG_CONFIG_HOME` if it's
available, but if not it falls back to the defaults defined by the
[xdg](https://github.com/adrg/xdg) package. Unfortunately the defaults
the package falls back to isn't what CLI applications commonly fall back
to on macOS. Specifically, it looks in `~/Library/Application Support`
instead of `~/.config`.
This updates the app config logic to:
- Look for `~/.config/lazygit` first if `XDG_CONFIG_HOME` is not set
and we're on macOS.
- Fallback to the existing `xdg` package location if the configuration
file exists there.
- Default to `~/.config/lazygit/config.yml` if `XDG_CONFIG_HOME` is not
set, we're on macOS, and there is no existing configuration file.
This change did feel a bit like having to thread a needle and I didn't
see any existing tests for this behavior (which is reasonable, since it's
complicated and OS dependent) so I did test a few variations of the
configuration locally by building with this change included and running
a `brew` installed lazygit.
It seemed to work properly, falling back to the existing location when
`XDG_CONFIG_HOME` isn't set, using `~/.config/lazygit` when `config.yml`
is present, and creating `~/.config/lazygit/config.yml` when it's not.
I think this should resolve https://github.com/jesseduffield/lazygit/issues/1341
When enabled, it adds "+n -m" after each file in the Files panel to show how
many lines were added and deleted, as with `git diff --numstat` on the command
line.
- Introduced a new optional user config command, allBranchesLogCmds
- When pressing 'a' in the Status view, cycle between non-empty, non-identical log commands
- There will always be at least one command to run, since allBranhesLogCmd has a default
- Update documentation & write an integration test
- Update translation string
This reverts commit 3af545daf7, reversing
changes made to 629b7ba1b8.
We changed our mind about this and want to provide different options for
achieving the same thing, but with more flexibility.
An inactive selection is one where the view is part of the context stack, but
not the active view. For example, the files view when you enter the staging
panel, or any view when you open a panel.
I often copy hashes in the commits panel in order to paste them into Github
comments (or other places), and I can't stand it when they have the full length.
I picked a default of 12 for this; I find this to be a good middle ground
between being reliable in large repos (12 still works in the linux kernel repo
today, but it might not be enough in really huge repos) and not being too ugly
(many smaller repos can probably get away with less).
We deliberately don't change this for the "Copy to clipboard" menu, since this
gives users a way to copy the unabbreviated sha if they need this occasionally.
By default we now search for substrings; you can search for multiple substrings
by separating them with spaces. Add a config option gui.filterMode that can be
set to 'fuzzy' to switch back to the previous behavior.
This requires us to change the 'v' keybinding for paste to something else,
now that 'v' is used globally for toggling range select. So I'm using
'shift+v' and I'm likewise changing 'c' to 'shift+c' for copying, so
that they're consistent.
We will need to clearly communicate this change in keybindings.
We're not fully standardising here: different contexts can store their range state however
they like. What we are standardising on is that now the view is always responsible for
highlighting the selected lines, meaning the context/controller needs to tell the view
where the range start is.
Two convenient benefits from this change:
1) we no longer need bespoke code in integration tests for asserting on selected lines because
we can just ask the view
2) line selection in staging/patch-building/merge-conflicts views now look the same as in
list views i.e. the highlight applies to the whole line (including trailing space)
I also noticed a bug with merge conflicts not rendering the selection on focus though I suspect
it wasn't a bug with any real consequences when the view wasn't displaying the selection.
I'm going to scrap the selectedRangeBgColor config and just let it use the single line
background color. Hopefully nobody cares, but there's really no need for an extra config.
