summaryrefslogtreecommitdiffstats
AgeCommit message (Collapse)Author
2024-02-16Simplify saving app stateStefan Haller
2024-02-16Migrate git.log.showGraph and git.log.order to app state (#3197)Stefan Haller
2024-02-16Redraw commits view when showGraph setting changesStefan Haller
2024-02-16Deprecate git.log.showGraph and git.log.order configAlex March
Added identical properties to AppState that should eventually have their defaults set.
2024-02-16Fix two problems related to update-ref rebase todo items (#3290)Stefan Haller
- **PR Description** This fixes two loosely related problems with `update-ref` todos: 1. Panic when hitting enter on an `update-ref` item 2. When selecting an `update-ref` item and then triggering a refresh, there was a bogus error message `fatal: ambiguous argument '': unknown revision or path not in the working tree.`
2024-02-16Avoid crash when hitting enter on an update-ref todoStefan Haller
2024-02-16Fix a problem with refreshing while an update-ref todo is selectedStefan Haller
Scenario: - show the files of a commit, escape out of it again - start an interactive rebase of a stack of branches, with the rebase.updateRefs git config set to true - select one of the update-ref todos - trigger a refresh (either manually or by bringing lazygit's terminal window to the front) This results in an error message "fatal: ambiguous argument '': unknown revision or path not in the working tree." Fix this by putting another band-aid on the check for the commit files refresh. This is the easiest way to fix the problem, but I don't think it's the best one. We shouldn't be refreshing the commit files context at all if it isn't visible, because it's pointless; there's no way to switch to it again except by calling viewFiles again with a specific ref. But I'm too lazy too figure out how to do that right now.
2024-02-16Support range select removing files from a commit (#3276)Jesse Duffield
- **PR Description** Support adding range select for removing multiple files from a commit. Closes #3260. The approaches I saw were to either modify `RebaseCommands.DiscardOldFileChanges` to accept multiple files or do the file removals as part of the custom patch workflow. I ended up going with the second way, but I'd be happy to re-implement with the first approach if that's preferred. I added a test that handles several different situations when removing commit files, and updated the original test for removing a single file from a commit. I changed how the user gets informed when removing files from a commit. The previous version had 2 prompts that I combined into 1 (because those two situations are now possible to see at the same time), and I added the total number of files that will be affected. This feature seems like it could cause some real damage if used improperly, so I'm trying to let the user know as much as possible. There are 2 or 3 i18n strings that I removed because they're no longer used. `RebaseCommands.DiscardOldFileChanges` isn't used anywhere any more, but I left it in there anyway. - **Please check if the PR fulfills these requirements** * [x] Cheatsheets are up-to-date (run `go generate ./...`) * [x] Code has been formatted (see [here](https://github.com/jesseduffield/lazygit/blob/master/CONTRIBUTING.md#code-formatting)) * [x] Tests have been added/updated (see [here](https://github.com/jesseduffield/lazygit/blob/master/pkg/integration/README.md) for the integration test guide) * [x] Text is internationalised (see [here](https://github.com/jesseduffield/lazygit/blob/master/CONTRIBUTING.md#internationalisation)) * [ ] Docs (specifically `docs/Config.md`) have been updated if necessary * [x] You've read through your own file changes for silly mistakes etc <!-- Be sure to name your PR with an imperative e.g. 'Add worktrees view' see https://github.com/jesseduffield/lazygit/releases/tag/v0.40.0 for examples -->
2024-02-13Fix range select bugAaron Hoffman
After discarding file changes from the commit, the was still referencing these indexes as being part of the range select. The consequence was needing to hit escape twice to exit commit files in some situations. Canceling the range select after discarding changes fixes that.
2024-02-13Clean up test caseAaron Hoffman
I'm combining the delete single file case from `discard_old_file_change` with the content of `discard_range_select` and calling that `discard_old_file_changes`. Hopefully that cleans things up a little bit. This also adds a check that the custom patch is getting reset properly.
2024-02-13CleanupAaron Hoffman
The waiting status shouldn't happen until after the user has responded to the popup. Since we're not giving a standalone prompt about clearing the patch, all of the business in `discard` doesn't need to be in a function any more
2024-02-13Support range select removing files from a commitAaron Hoffman
2024-02-13Change default of git.log.showGraph to 'always' (#3314)Stefan Haller
Change default of git.log.showGraph to 'always'; most people seem to prefer it to be on. Fixes #3312.
2024-02-13Change default of git.log.showGraph to 'always'Stefan Haller
Most people seem to prefer it to be on.
2024-02-12Disallow cherry-picking merge commits (#3316)Stefan Haller
Cherry-picking merge commits is currently not supported because of the way copy/pasting is currently implemented. Disable the command with a proper error message if the user tries to copy a merge commit, instead of running into the confusing error message that git would otherwise give, see #1374. While we're at it, disable it also when trying to copy an "update-ref" todo, which doesn't make sense.
2024-02-10Disallow cherry-picking merge commitsStefan Haller
2024-02-10Disallow cherry-picking update-ref todosStefan Haller
2024-02-10Cleanup: remove unused methodStefan Haller
2024-01-30Fix cherrypick demo (#3287)Stefan Haller
Cherrypick selections are now cleared after pasting (#3240), so the demo needs a tiny change to reflect that. - **PR Description** The cherry pick demo is failing after the changes in #3240. This is just a small update to that demo to reflect the new (and more convenient) behavior from #3240. - **Please check if the PR fulfills these requirements** * [x] Cheatsheets are up-to-date (run `go generate ./...`) * [x] Code has been formatted (see [here](https://github.com/jesseduffield/lazygit/blob/master/CONTRIBUTING.md#code-formatting)) * [x] Tests have been added/updated (see [here](https://github.com/jesseduffield/lazygit/blob/master/pkg/integration/README.md) for the integration test guide) * [ ] Text is internationalised (see [here](https://github.com/jesseduffield/lazygit/blob/master/CONTRIBUTING.md#internationalisation)) * [ ] Docs (specifically `docs/Config.md`) have been updated if necessary * [x] You've read through your own file changes for silly mistakes etc <!-- Be sure to name your PR with an imperative e.g. 'Add worktrees view' see https://github.com/jesseduffield/lazygit/releases/tag/v0.40.0 for examples -->
2024-01-30Fix cherrypick demoAaron Hoffman
Cherrypick selections are now cleared after pasting (#3240), so the demo needs a tiny change to reflect that.
2024-01-30Clear cherry-picked commits after pasting (#3240)Stefan Haller
It can be tedious after each cherry-pick opearation to clear the selection by pressing escape in order for lazygit to stop displaying info about copied commits. Also, it seems to be a rare case to cherry-pick commits to more than one destination. The simplest solution to address this issue is to clear the selection upon paste, including merge conflict scenario. Previously discussed in #3198.
2024-01-30Clear cherry-picked commits after pastingmolejnik88
It can be tedious after each cherry-pick opearation to clear the selection by pressing escape in order for lazygit to stop displaying info about copied commits. Also, it seems to be a rare case to cherry-pick commits to more than one destination. The simplest solution to address this issue is to clear the selection upon paste. The only exception is a merge conflict. Initially, I wanted to clear selected commits in this scenario too. During a discussion we found out that it may be convenient to have the copied commits still around. Aborting the rebase and pasting the commits in the middle of a branch can be a valid use case.
2024-01-30Use slimmer scrollbars (#3283)Jesse Duffield
(hopefully) fixes https://github.com/jesseduffield/lazygit/issues/1924 The previous scrollbars were too chunky and encroached too much on a view's content. The new ones are slim and right-aligned so they encroach into dead space between views which is much better. Before: ![image](https://github.com/jesseduffield/lazygit/assets/8456633/fe125804-0cb8-4f9b-be4c-5710fd73ac14) After: ![image](https://github.com/jesseduffield/lazygit/assets/8456633/8ae18f96-e2fd-46ff-be9a-09e745da1177) Admittedly, the original scrollbars look more like typical scrollbars and do a better job at telling you where the start and end of the scrollbar is. We experimented with having special characters for scrollbar bounds in the slim version but it all looked pretty ugly, and there's just not many ascii characters to choose from. Based on gocui PR: https://github.com/jesseduffield/gocui/pull/45 The important changes are in vendor/github.com/jesseduffield/gocui/gui.go vendor/github.com/jesseduffield/gocui/scrollbar.go The other changes are just modules being updated. - **PR Description** - **Please check if the PR fulfills these requirements** * [x] Cheatsheets are up-to-date (run `go generate ./...`) * [x] Code has been formatted (see [here](https://github.com/jesseduffield/lazygit/blob/master/CONTRIBUTING.md#code-formatting)) * [x] Tests have been added/updated (see [here](https://github.com/jesseduffield/lazygit/blob/master/pkg/integration/README.md) for the integration test guide) * [x] Text is internationalised (see [here](https://github.com/jesseduffield/lazygit/blob/master/CONTRIBUTING.md#internationalisation)) * [x] Docs (specifically `docs/Config.md`) have been updated if necessary * [x] You've read through your own file changes for silly mistakes etc <!-- Be sure to name your PR with an imperative e.g. 'Add worktrees view' see https://github.com/jesseduffield/lazygit/releases/tag/v0.40.0 for examples -->
2024-01-30Use slimmer scrollbarsJesse Duffield
The previous scrollbars were too chunky and encroached too much on a view's content. The new ones are slim and right-aligned so they encroach into dead space between views which is much better
2024-01-29Add command to squash all fixups in the current branch (#3274)Stefan Haller
Add command to squash all fixups in the current branch. To do that, change the "Apply fixup commits" command to show a menu with the two choices "in current branch" and "above the selected commit"; we make "in current branch" the default, as it's the more useful one most of the time, even though it is a breaking change for those who are used to "shift-S enter" meaning "squash above selected". Fixes #3263.
2024-01-29Add command to squash all fixups in the current branchStefan Haller
To do that, change the "Apply fixup commits" command to show a menu with the two choices "in current branch" and "above the selected commit"; we make "in current branch" the default, as it's the more useful one most of the time, even though it is a breaking change for those who are used to "shift-S enter" meaning "squash above selected".
2024-01-28Fix refreshing custom patch view when adding first file to custom patch (#3266)Stefan Haller
Fixes #3258.
2024-01-28Fix main view refresh after adding the first file to a custom patchStefan Haller
This broke with 240948b.
2024-01-28Fix typoStefan Haller
2024-01-28Support selecting file range in patch builder (#3259)Jesse Duffield
- **PR Description** Adds support for selecting a range of files and adding them to a custom patch. Closes #3251 The behavior for node selection is the same as used in #3248 because I copied the approach. Please let me know if there's a mismatch or if something else is preferred. I also copied `normalisedSelectedNodes` and `isDescendentOfSelectedNodes` verbatim, just adapted their signature types. It seems like we could share those two functions between `[]*filetree.CommitFileNode` and `[]*filetree.FileNode` by making those functions like `func normalisedSelectedCommitNodes[T any](selectedNodes []*filetree.Node[T]) []*filetree.Node[T]`. That would require calling them with a `lo.Map(...)` which returns `node.GetRaw()`, and I feel weird about giving a different type back to the calling function. I added a couple of test cases, and all of the existing patch tests pass for me, but please do let me know if there are any other test cases I should add. - **Please check if the PR fulfills these requirements** * [x] Cheatsheets are up-to-date (run `go generate ./...`) * [x] Code has been formatted (see [here](https://github.com/jesseduffield/lazygit/blob/master/CONTRIBUTING.md#code-formatting)) * [x] Tests have been added/updated (see [here](https://github.com/jesseduffield/lazygit/blob/master/pkg/integration/README.md) for the integration test guide) * [ ] Text is internationalised (see [here](https://github.com/jesseduffield/lazygit/blob/master/CONTRIBUTING.md#internationalisation)) * [ ] Docs (specifically `docs/Config.md`) have been updated if necessary * [x] You've read through your own file changes for silly mistakes etc <!-- Be sure to name your PR with an imperative e.g. 'Add worktrees view' see https://github.com/jesseduffield/lazygit/releases/tag/v0.40.0 for examples -->
2024-01-28Support selecting file range in patch builderAaron Hoffman
test: add move_range_to_index test: add toggle_range
2024-01-28Warn users when attempting to cherry pick with old key (#3271)Jesse Duffield
I wrote this feature and even I sometimes use the wrong key so I want to make this very clear to users so that there's no confusion. We can get rid of this once users have had time to adjust ![image](https://github.com/jesseduffield/lazygit/assets/8456633/8a453eaf-381d-468e-8280-58516eead43a) - **Please check if the PR fulfills these requirements** * [x] Cheatsheets are up-to-date (run `go generate ./...`) * [x] Code has been formatted (see [here](https://github.com/jesseduffield/lazygit/blob/master/CONTRIBUTING.md#code-formatting)) * [x] Tests have been added/updated (see [here](https://github.com/jesseduffield/lazygit/blob/master/pkg/integration/README.md) for the integration test guide) * [x] Text is internationalised (see [here](https://github.com/jesseduffield/lazygit/blob/master/CONTRIBUTING.md#internationalisation)) * [x] Docs (specifically `docs/Config.md`) have been updated if necessary * [x] You've read through your own file changes for silly mistakes etc <!-- Be sure to name your PR with an imperative e.g. 'Add worktrees view' see https://github.com/jesseduffield/lazygit/releases/tag/v0.40.0 for examples -->
2024-01-28Warn users when attempting to cherry pick with old keyJesse Duffield
I wrote this feature and even I sometimes use the wrong key so I want to make this very clear to users so that there's no confusion
2024-01-28Show better keybinding suggestions (#3203)Jesse Duffield
- **PR Description** This PR's goal is to improve discoverability of keybindings in lazygit. I've have a couple people in real life mention to me that it wasn't obvious what key to press for viewing rebase options, for example. This PR: * shows more keybindings in the options view * shows certain keybindings prominently in certain modes e.g. 'view rebase options: m' when mid-rebase. Before: ![image](https://github.com/jesseduffield/lazygit/assets/8456633/483477ef-93e1-4fd1-af86-3ffa84167f62) After: ![image](https://github.com/jesseduffield/lazygit/assets/8456633/4c93dd19-f072-45ec-afa6-810727211f66) - **Please check if the PR fulfills these requirements** * [x] Cheatsheets are up-to-date (run `go generate ./...`) * [x] Code has been formatted (see [here](https://github.com/jesseduffield/lazygit/blob/master/CONTRIBUTING.md#code-formatting)) * [x] Tests have been added/updated (see [here](https://github.com/jesseduffield/lazygit/blob/master/pkg/integration/README.md) for the integration test guide) * [x] Text is internationalised (see [here](https://github.com/jesseduffield/lazygit/blob/master/CONTRIBUTING.md#internationalisation)) * [x] Docs (specifically `docs/Config.md`) have been updated if necessary * [x] You've read through your own file changes for silly mistakes etc <!-- Be sure to name your PR with an imperative e.g. 'Add worktrees view' see https://github.com/jesseduffield/lazygit/releases/tag/v0.40.0 for examples -->
2024-01-28Reduce the chance of race condition with list cursorJesse Duffield
Before this commit, we had pkg/integration/tests/submodule/add.go failing with a panic. I'm pretty sure the issue is this: we're now calling quite a few GetDisabledReason calls on each layout() call, and if a background thread happens to update a model slice while we're doing this, we can end up with a selection index that's now out of bounds because it hasn't been clamped to match the new list length. Specifically, here we had the selected index being -1 (the list starts empty and somehow the value is -1 in this case) and then the list gets a new submodule so the length is now 1, but the list cursor doesn't know about this so remains on the old value. Then we confirm the length is greater than zero and try to get the selected submodule and get an out of bounds error. This commit fixes the issue by clamping the selected index whenever we get the length of the list so that it stays in-sync. This is not a perfect solution because the length can change at any time, but it seems to reliably fix the test, and using mutexes didn't seem to make a difference. Note that we're swapping the order of IFileTree and IListCursor in the file tree view model to ensure that the list cursor's Len() method is called (which performs the clamping). Also, comment from the PR: This 'trait' pattern we're using is convenient but can lead to awkward situations. In this case we have both the list view model and the (embedded) list cursor with a Len() method. The list cursor Len() method just calls the list view model Len() method. But I wanted to make it that the list view model now calls ClampSelection() on the list cursor whenever it obtains the length. This will cause an infinite loop because ClampSelection() internally calls Len() (which calls the list view model's Len() method which in turn calls ClampSelection() again, etc). The only reason we were passing the list view model into the list cursor was to supply the length method, so now we're just doing that directly, and letting the list view model delegate the Len() call to the list cursor, which now itself calls ClampSelection.
2024-01-28Display more keybindings on-screenJesse Duffield
2024-01-28Show mode-specific keybinding suggestionsJesse Duffield
As part of making lazygit more discoverable, there are certain keys which you almost certainly need to press when you're in a given mode e.g. 'v' to paste commits when cherry-picking. This commit prominently shows these keybinding suggestions alongside the others in the option view. I'm using the same colours for these keybindings as is associated with the mode elsewhere e.g. yellow for rebasing and cyan for cherry-picking. The cherry-picking one is a bit weird because we also use cyan text to show loaders and app status at the bottom left so it may be confusing, but I haven't personally found it awkward from having tested it out myself. Previously we would render these options whenever a new context was activated, but now that we need to re-render options whenever a mode changes, I'm instead rendering them on each screen re-render (i.e. in the layout function). Given how cheap it is to render this text, I think it's fine performance-wise.
2024-01-28Ensure file view length is never returned as -1Jesse Duffield
This was causing issues when obtaining selected items
2024-01-28Add loads of tooltips (#3269)Jesse Duffield
- **PR Description** This is cherry-picked from https://github.com/jesseduffield/lazygit/pull/3203. That PR both adds tooltips and adds keybinding suggestions, and the latter part is having some concurrency issues that I want to properly fix before merging. - **Please check if the PR fulfills these requirements** * [x] Cheatsheets are up-to-date (run `go generate ./...`) * [x] Code has been formatted (see [here](https://github.com/jesseduffield/lazygit/blob/master/CONTRIBUTING.md#code-formatting)) * [x] Tests have been added/updated (see [here](https://github.com/jesseduffield/lazygit/blob/master/pkg/integration/README.md) for the integration test guide) * [x] Text is internationalised (see [here](https://github.com/jesseduffield/lazygit/blob/master/CONTRIBUTING.md#internationalisation)) * [x] Docs (specifically `docs/Config.md`) have been updated if necessary * [x] You've read through your own file changes for silly mistakes etc <!-- Be sure to name your PR with an imperative e.g. 'Add worktrees view' see https://github.com/jesseduffield/lazygit/releases/tag/v0.40.0 for examples -->
2024-01-28Improve keybinding descriptionsJesse Duffield
This adds a bunch of tooltips to keybindings and updates some keybinding descriptions (i.e. labels). It's in preparation for displaying more keybindings on-screen (in the bottom right of the screen), and so due in part to laziness it shortens some descriptions so that we don't need to manage both a short and long description (for on-screen vs in-menu). Nonetheless I've added a ShortDescription field for when we do want to have both a short and long description. You'll notice that some keybindings I deemed unworthy of the options view have longer descriptions, because I could get away with it.
2024-01-28Render keybinding cheatsheet as markdown tableJesse Duffield
We're going to be adding tooltips to the cheatsheet to better explain what each actions does. As such, we're switching to a table format rather than a list. I'm also changing how the keys are represented, using a markdown approach rather than an html approach
2024-01-26Keep same selection range when quick-starting an interactive rebase (#3247)Stefan Haller
This is useful if you want to move a range of commits, so you select them, and then realize it's better to do it in an interactive rebase. Pressing 'i' preserves the range now.
2024-01-26Keep same selection range when quick-starting an interactive rebaseStefan Haller
This is useful if you want to move a range of commits, so you select them, and then realize it's better to do it in an interactive rebase. Pressing 'i' preserves the range now.
2024-01-26Add tests for preserving the selection when pressing 'i'Stefan Haller
Preserving the selection for a non-range selection already works as expected; however, the test for a selection range shows an undesired behavior.
2024-01-26Rename MinMax to SortRangeStefan Haller
2024-01-26Add shortcuts for filtering files by status (#3137)Jesse Duffield
- 's' for showing only staged files - 'u' for showing only unstaged files - 'r' for resetting the filter - **PR Description** - **Please check if the PR fulfills these requirements** * [x] Cheatsheets are up-to-date (run `go generate ./...`) * [x] Code has been formatted (see [here](https://github.com/jesseduffield/lazygit/blob/master/CONTRIBUTING.md#code-formatting)) * [x] Tests have been added/updated (see [here](https://github.com/jesseduffield/lazygit/blob/master/pkg/integration/README.md) for the integration test guide) * [x] Text is internationalised (see [here](https://github.com/jesseduffield/lazygit/blob/master/CONTRIBUTING.md#internationalisation)) * [x] Docs (specifically `docs/Config.md`) have been updated if necessary * [x] You've read through your own file changes for silly mistakes etc <!-- Be sure to name your PR with an imperative e.g. 'Add worktrees view' see https://github.com/jesseduffield/lazygit/releases/tag/v0.40.0 for examples --> I've thought about adding `disabled` reasons for them but they kinda don't make sense since if there are only `unstaged` files, disabling the `Show only staged files` makes no sense because the `Show only unstaged files` shows nothing different so we should disable that too, and then what's the point of having a menu if everything except for `reset` is disabled.
2024-01-26Add shortcuts for filtering files by statusLuka Markušić
- 's' for showing only staged files - 'u' for showing only unstaged files - 'r' for resetting the filter
2024-01-26Inline status for fetching remotes (#3238)Stefan Haller
When fetching a remote in the remotes tab, show the status inline (i.e. in the list row of the remote), like we do when fast-forwarding a branch in the branches panel.
2024-01-26Remove unused text FetchingRemoteStatusStefan Haller
We just removed the last use of it.
2024-01-26Use inline status for fetching remotesStefan Haller