Repository navigation
Let the user continue or abort a squash merge - #6197
Merged
Merged
Conversation
If the checked-out branch can be fast-forwarded to the selected branch, "git merge --squash" doesn't refuse to run while there are staged changes, unlike a merge that can't be fast-forwarded. It adds the changes of the branch to the ones that are already staged. "Squash merge and commit" then commits the staged changes along with the squashed ones, without the user noticing. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Git refuses to merge a branch while there are staged changes, unless the merge is a fast-forward. A fast-forward keeps the staged changes as they are. A squash merge that git can fast-forward adds the changes of the branch to them, though, and "Squash merge and commit" then commits them all. Disable both squash merge items in the merge menu while there are staged changes, so that squash merges behave like other merges. We will rely on this when we let the user abort a squash merge. Aborting resets the staged changes, so they must all come from the merge. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
…y-pick If a merge, cherry-pick, revert or "git am" stops with conflicts, users often edit the files that git changed, for example to fix the build. If they then decide to give up and abort, git fails with "Entry 'file' not uptodate. Cannot merge." It keeps unstaged changes when aborting, but it can't reset the staged changes of a file underneath them. "git am --abort" even stops halfway, after it has reset the conflicted files. Git refuses to start any of these operations if there are staged changes, or if a file that it has to change has unstaged changes. So unstaged changes on top of staged ones were made after git stopped. Discard them before aborting, but ask the user first, listing the files. A rebase doesn't need this, because "git rebase --abort" discards all changes. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
GenericMergeOrRebaseAction takes the name of the git command whose --continue, --skip or --abort option it runs. We are about to show a squash merge as an operation in progress, and it has no such command. "git merge --continue" and "git merge --abort" refuse to run without MERGE_HEAD, and a squash merge doesn't write it. Pass the working tree state instead, so that GenericMergeOrRebaseAction can decide which commands to run. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
If a squash merge stops with conflicts, lazygit doesn't show a merge in progress, because "git merge --squash" doesn't write MERGE_HEAD. After resolving the conflicts, users have to commit the changes themselves, and type the message that "Squash merge and commit" would have used. To give up, they have to discard the changes. The "Abort the merge" item of the conflicts menu fails with "You are currently neither rebasing nor merging". "git merge --squash" writes SQUASH_MSG, a message for committing the changes. Git removes it when the changes are committed, reset or stashed, and when switching branches. Show a merge in progress while the file exists. Continue it with "git commit", and abort it with "git reset --merge", like "git merge --abort" does. Write the configured squashMergeMessage into SQUASH_MSG, so that continuing uses it. Do this for "Squash merge and leave uncommitted" too, so that both variants make the same commit. A merge in progress is now shown after this variant until the user commits the changes. We don't offer to continue it when its conflicts are resolved, though, because the user asked us not to commit. Select the new commit after "Squash merge and commit", like after other merges. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
After "Squash merge and leave uncommitted", the commit panel opens empty, or with the commit prefix of the branch. Users have to type a message for the squash merge themselves. "git commit" from the terminal suggests the message in SQUASH_MSG instead. Show the message in SQUASH_MSG in the commit panel, unless there is a preserved message. It takes precedence over the commit prefix, like the message of "Squash merge and commit" does. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Discarding a file or directory in the files panel runs git commands on these paths only, and these leave SQUASH_MSG alone. If users discard all changes of a squash merge this way, lazygit keeps showing a merge in progress, and the next commit gets the squash merge message. Abort the squash merge after "Discard all changes" if no changes are left. Untracked files don't count, because a squash merge stages the files that it adds. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
If a squash merge stops with conflicts, lazygit didn't show a merge in progress, because "git merge --squash" doesn't write MERGE_HEAD. After resolving the conflicts, users had to commit the changes themselves, and type the message that "Squash merge and commit" would have used. To give up, they had to discard the changes. The "Abort the merge" item of the conflicts menu failed with "You are currently neither rebasing nor merging".
Improve this by showing a merge in progress when a "Squash merge and commit" fails with conflicts, so that users can continue or abort it like they would with a regular merge. We even enter this state after "Squash merge and leave uncommitted", so that users can use the
mmenu to continue and create a commit with the right message. This is a change in behavior that I hope won't disturb anyone's workflows; please file an issue if it does.