Skip to content

Conversation

stefanhaller
Copy link
Collaborator

This will put whatever git's default merge variant is as the first menu item, and add a second item which is the opposite (no-ff if the default is ff, and vice versa). Which one is the default depends on whether a fast-forward merge is possible, and whether users have set git's merge.ff config or lazygit's git.merging.args config.

image

If users prefer to always have the same option first no matter whether it's applicable, they can make ff always appear first by setting git's merge.ff config to "true" or "only", or by setting lazygit's git.merging.args config to "--ff" or "--ff-only"; if they want no-ff to appear first, they can do that by setting git's merge.ff config to "false", or by setting lazygit's git.merging.args config to "--no-ff". Which of these they choose depends on whether they want the config to also apply to other git clients including the cli, or only to lazygit.

Closes #4091.

Copy link

codacy-production bot commented Oct 15, 2025

Coverage summary from Codacy

See diff coverage on Codacy

Coverage variation Diff coverage
Report missing for d334bae1 96.46%
Coverage variation details
Coverable lines Covered lines Coverage
Common ancestor commit (d334bae) Report Missing Report Missing Report Missing
Head commit (6285402) 58833 51216 87.05%

Coverage variation is the difference between the coverage for the head and common ancestor commits of the pull request branch: <coverage of head commit> - <coverage of common ancestor commit>

Diff coverage details
Coverable lines Covered lines Diff coverage
Pull request (#4966) 254 245 96.46%

Diff coverage is the percentage of lines that are covered by tests out of the coverable lines that the pull request added or modified: <covered lines added or modified>/<coverable lines added or modified> * 100%

See your quality gate settings    Change summary preferences

Footnotes

  1. Codacy didn't receive coverage data for the commit, or there was an error processing the received data. Check your integration for errors and validate that your coverage setup is correct.

- Squash and FastForwardOnly are mutually exclusive, and instead of asserting
  this at runtime, model the API so that they can't be passed together.
- FastForwardOnly is unused, so remove it; however, we are going to need --ff
  and --no-ff in the next commit, so add those instead.
- Instead of putting the enum into the MergeOpts struct, replace the struct by
  the enum. We can reintroduce the struct when we add more arguments, but for
  now it's an unnecessary indirection.
This will put whatever git's default merge variant is as the first menu item,
and add a second item which is the opposite (no-ff if the default is ff, and
vice versa).

If users prefer to always have the same option first no matter whether it's
applicable, they can make ff always appear first by setting git's "merge.ff"
config to "true" or "only", or by setting lazygit's "git.merging.args" config to
"--ff" or "--ff-only"; if they want no-ff to appear first, they can do that by
setting git's "merge.ff" config to "false", or by setting lazygit's
"git.merging.args" config to "--no-ff". Which of these they choose depends on
whether they want the config to also apply to other git clients including the
cli, or only to lazygit.
@stefanhaller stefanhaller merged commit 6782f04 into master Oct 19, 2025
13 checks passed
@stefanhaller stefanhaller deleted the add-non-ff-merge branch October 19, 2025 19:26
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

enhancement New feature or request

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Can we have a no-ff (non-fast forward) merge? Revisit #785

1 participant