1
0
mirror of https://github.com/jesseduffield/lazygit.git synced 2025-07-15 11:41:50 +03:00
Commit Graph

596 Commits

Author SHA1 Message Date
5b1292006d Add new command "Checkout previous branch" 2025-07-12 18:17:25 +02:00
bf19475733 Fix more unstable tests
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.
2025-07-10 08:59:01 +02:00
4981419ba9 Fix stale main view content when entering/exiting filtering view
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.
2025-07-09 16:00:46 +02:00
457cdce61d Fix unstable tests
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.
2025-07-09 16:00:46 +02:00
df48667253 Add a prompt for the sort order menus for branches 2025-07-09 13:16:42 +02:00
562a2aaa6b Un-deprecate UserConfig.Git.Log.Order and ShowGraph
And remove them from AppState.
2025-07-09 13:15:03 +02:00
703256e92d Move LocalBranchSortOrder and RemoteBranchSortOrder to user config
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).
2025-07-09 13:15:03 +02:00
c739357eb9 Remove git version specific code for versions we no longer support 2025-07-09 12:18:58 +02:00
93c5849c86 Remove obsolete git version restrictions 2025-07-09 12:18:57 +02:00
6a9fe2e604 Remove obsolete tests
These only ran for git versions that we no longer support.
2025-07-09 12:18:57 +02:00
a1a2925c9c Remove obsolete git version restriction in test
We have been requiring 2.22 for a while now.
2025-07-09 11:15:45 +02:00
7153305174 Add confirmation for hard reset when there are uncommitted changes 2025-07-08 16:41:22 +02:00
a6096f4702 In hunk staging mode, select blocks of changes rather than actual hunks
Also, pressing right or left arrow moves between blocks of changes rather than
actual hunks. I find this to be much more useful.
2025-07-04 19:31:35 +02:00
039831a27a Move to next stageable line after adding a line to a custom patch
While it's true that the behavior is a little different from the staging panel,
where the staged lines are actually removed from the view and in many cases the
selection stays more or less in the same place, it is still very useful to move
to the next stageable thing in the custom patch building view too.
2025-07-04 10:14:35 +02:00
dc795b5db7 Remove unnecessary refresh
CheckMergeOrRebase calls Refresh already. However, it does an async refresh by
default, so we must turn this into a sync refresh so that moving the selection
down by one works even for the very first commit in history. Also, we must add
an explicit call to FocusLine so that the view selection is in sync with the
model selection; previously this was taken care of by the PostRefreshUpdate call
that happens as part of a refresh.
2025-07-03 17:04:10 +02:00
0fc107c8c1 Adjust selection after cherry-picking commits
Keep the same commit selected, by moving the selection down by the number of
cherry-picked commits. We also do this when reverting commits, and it is
possible now that we use a sync waiting status.

We also need to turn the refresh that happens as part of CheckMergeOrRebase into
a sync one, so that the commits list is up to date and the new selection isn't
clamped.
2025-07-03 17:04:10 +02:00
09a4e0b209 Add selection assertions to cherry-pick tests
We are about to change the selection behavior when cherry-picking, and it's good
to have tests that document in what way it changes in the next commit.
2025-07-03 16:58:56 +02:00
3df894ec92 Stage affected unstaged files when applying or reverting a patch
Unlike moving a patch to the index, applying or reverting a patch didn't
auto-stash, which means that applying a patch when there's a modified (but
unstaged) file in the working tree would error out with the message "error:
file1: does not match index", regardless of whether those modifications conflict
with the patch or not.

To fix this, we *could* add auto-stashing like we do for the "move patch to
index" command. However, in this case we rather simply stage the affected files
(after asking for confirmation). This has a few advantages:

- it only changes the staging state of those files that are contained in the
patch (whereas auto-stashing always changes all files to unstaged)
- it doesn't unnecessarily show a confirmation if none of the modified files are
affected by the patch
- if the patch conflicts with the modified files, the conflicts were "backwards"
("ours" was the patch, "theirs" the modified file); it is more logical if "ours"
is the current state of the file, and "theirs" is the patch.

It's a little unfortunate that the behavior isn't exactly the same as for "move
patch to index", but for that one we do need the auto-stash because of the
rebase that runs behind the scenes.
2025-07-02 16:19:06 +02:00
c440a208a6 Add tests for applying a patch when there's a modified file
The tests show that this currently fails with the confusing error message "does
not match index", regardless of whether the patch conflicts with the
modifications or not. We'll improve this in the next commit.

I don't bother adding tests for reverting a patch, as the code is basically the
same as for apply.
2025-07-02 16:19:06 +02:00
32bd9e6029 Drop stash when successfully unstashing files after moving patch to index 2025-07-02 16:19:06 +02:00
823aa640b9 Add test for moving patch to index when there's a modified file
This is functionality that works already, we only add the test for more complete
test coverage. However, there's a detail problem, and the test demonstrates
this: we keep the stash even if there was no conflict. We'll fix this next.
2025-07-02 16:19:06 +02:00
0471dbaa84 Enable intrange linter, and fix warnings 2025-06-30 18:30:11 +02:00
03abdfcfe2 Fix the CurrentBranchName function
The function would return "head/branchname" when there was either a tag or a
remote with the same name.

While fixing this we slightly change the semantic of the function (and of
determineCheckedOutBranchName, which calls it): for a detached head it now
returns an empty string rather than the commit hash. I actually think this is
better.
2025-06-30 16:08:03 +02:00
61815c10e7 Add a test showing undesired branch icon at head commit
The icon will appear when there's a tag with the same name as the current branch
(that's what we're testing here), or even when there's a remote with the same
name. I'm not adding a test for this latter case, but this was actually how I
discovered the issue.
2025-06-30 16:08:03 +02:00
265557afa2 Add unambigious refs/ prefix to all stash references
Pretty basic fix, didn't seem to have any complications.
I only added the refs/ prefix to the FullRefName() method
to align with other similar methods, and to make this change
not impact any user facing modals.

Fixes: https://github.com/jesseduffield/lazygit/issues/4634

Also adds a test demonstrating that the stash show behavior is now fixed
2025-06-15 16:14:59 +02:00
706891e92b Add integration test for resetting to upstream branch with duplicate name 2025-06-04 20:43:01 +02:00
737a99b1c8 Add integration tests showing resetting to duplicate named tags and branches 2025-06-04 20:43:01 +02:00
fdf9726c37 Use branchPrefix on moving commits to a new branch
Signed-off-by: Elias Assaf <elyas51000@gmail.com>
2025-05-29 22:39:26 +02:00
3cff48437e Add user config gui.addRootItemInFileTree 2025-05-24 18:17:25 +02:00
e67bc45d48 Split behavior of rendering allBranchesLogCmd and switching to next cmd
This now allows for leaving the status panel and returning back to the
same log command. Previously any return to the status panel would result
in the next command in the list being shown. Now, you need to press `a`,
with a log command being rendered, to rotate to the next
allBranchesLogCmd.
2025-05-21 08:17:09 +02:00
f6d13330dd Add custom patch command "Move patch into new commit before the original commit"
This is often useful to extract preparatory refactoring commits from a bigger
one.
2025-05-10 18:57:28 +02:00
5321101276 Use 'break' instead of 'edit' for BeginInteractiveRebaseForCommit with merge commit
BeginInteractiveRebaseForCommit is used for all the patch commands, and for
rewording. It works by setting the commit we want to stop at to 'edit'; this
doesn't work for merge commits. This wasn't a problem for the patch commands so
far, because you typically don't use custom patches with merge commits (although
we don't prevent this; maybe we should?).

However, it was a problem when you tried to reword a merge commit; this
previously failed with an error, as the test added in the previous commit
demonstrated.

Also, we want to add a new patch command that has to stop *before* the selected
commit (pull patch to new commit before the original one), and this wouldn't
work for the first commit in a feature branch, because it would have to set the
last commit before that to 'edit', which isn't possible if that's a merge (which
is likely).

To fix all this, use a 'break' before the selected commit if the commit is a
merge. It is important that we only do it in that case and not always, otherwise
we would break the new regression tests that were added a few commits ago.
2025-05-10 18:44:31 +02:00
50b2aa5843 Add test for rewording a merge commit
This currently fails with an error.
2025-05-10 18:19:35 +02:00
b02441cdca Regression test for moving custom patch to new commit from last commit of a stacked branch
I almost broke this during the development of this branch, so add a test to
guard against that. The point here is that the stack remains intact, i.e. the
newly created commit is the last commit of the lower branch, and thus shows the
"*".
2025-05-10 18:19:35 +02:00
0c0f95168c Regression test for renaming the last commit of a stacked branch
I almost broke this during the development of this branch, so add a test to
guard against that. The point here is that the stack remains intact, i.e. the
renamed commit is the head of the lower branch, and thus shows the "*".
2025-05-10 18:19:09 +02:00
144565ee03 Cleanup: remove unnecessary setup steps 2025-05-10 18:15:42 +02:00
1028f8efb8 Migrate deprecated AllBranchesLogCmd to AllBranchesLogCmds
This solves https://github.com/jesseduffield/lazygit/issues/3961 because
we no longer have a combination of the default and the user defined
list. We just have the user defined list.
2025-05-06 23:33:17 -04:00
a9f9dee30d Combine customCommand's subprocess, stream, and showOutput fields into a single output enum 2025-05-01 15:46:06 +02:00
6402c830d5 Remove space after rebase todo
This is very old; I can only guess that this was added at a time where today's
list column handling wasn't in place yet, so the space was needed to separate
columns. This now causes a gap of two spaces between the rebase todo column and
the author column, which I'm sure wasn't intended. Funny that I never noticed.
2025-04-29 11:30:37 +02:00
da24deb881 Allow changing diff context size and rename threshold when main view is focused 2025-04-23 08:38:46 +02:00
30868eead8 Add new command "Move commits to new branch" 2025-04-21 18:12:50 +02:00
eaaa937315 Add config for auto-forwarding branches after fetching 2025-04-21 18:06:09 +02:00
acfa024915 Allow clicking in main view to focus it 2025-04-21 18:03:24 +02:00
2a2705dcc3 Always render diffs to the main/secondary context pair, even for files
Previously we would render the diff for a directory to the main/secondary pair,
but a diff for a file to the staging/stagingSecondary pair. (And similar for
commit files: main/secondary for directories, but
patchBuilding/patchBuildingSecondary for files.)

I always found this confusing and couldn't really understand why we are doing
this; but now it gets in my way because I want to attach a controller to
main/secondary so that they can be focused. So change it to always use the main
context pair for everything we render from a side panel.
2025-04-21 18:03:18 +02:00
74054c9d70 Remove the "YOU ARE HERE" marker
Now that we have sections, it is no longer needed.

Keep the "<-- CONFLICTS" marker though.
2025-04-20 16:06:15 +02:00
6cbc1e0ace Add section headers for rebase todos, cherry-picks, reverts, and actual commits 2025-04-20 16:06:15 +02:00
e90a3dc666 Fix view selection running out of sync with list selection when view isn't focused
When rerendering a view at the end of a refresh, we call HandleFocus only if the
view has the focus. This is so that we rerender the main view for the new
selection.

What was missing here is to update the view selection from the list selection if
the view doesn't have the focus, so that the selection is painted properly.
Normally this is not relevant because you don't see the selection if another
side panel has the focus; however, you do see it as an inactive selection when
e.g. a popup is shown, in which case it does matter.

This will become more important when we introduce section headers for commits,
because in that case the view selection needs to change when the working copy
state changes from normal to rebasing or vice versa, even if the list selection
stays the same.

The changed test submodule/reset.go shows how this was wrong before: when
entering the submodule again after resetting, there is a refresh which keeps the
same branch selected as before (master); however, since the branches panel is
not focused, the view didn't notice and kept thinking that the detached head is
selected (which it isn't, you can tell by running the test in sandbox mode and
focusing the branches panel at the end: you'll see that master is selected). So
the change in this commit fixes that.
2025-04-20 16:06:15 +02:00
945b023eb5 Support range selection for reverting commits 2025-04-20 16:03:06 +02:00
f14a3cdd46 Remove the "Select parent commit" prompt when reverting a merge commit
In pretty much 100% of the cases, you want to use -m1, so spare users the
complexity of a confusing prompt.

See
https://public-inbox.org/git/e60a8b1a-98c8-4ac7-b966-ff9635bb781d@haller-berlin.de/
for some discussion.
2025-04-20 16:03:06 +02:00
108054efc6 Allow cherry-picking merge commits
Now that we use git cherry-pick to implement it, there's no reason not to.
2025-04-20 15:59:48 +02:00