Also see the git-commit(1) manpage.
magit-commit) ¶This transient prefix command binds the following suffix commands along with the appropriate infix arguments and displays them in a temporary buffer until a suffix is invoked.
magit-commit-create) ¶Create a new commit on HEAD. With a prefix argument amend to the
commit at HEAD instead.
magit-commit-amend) ¶Amend the last commit.
magit-commit-extend) ¶Amend the last commit, without editing the message. With a prefix
argument keep the committer date, otherwise change it. The option
magit-commit-extend-override-date can be used to inverse the meaning
of the prefix argument.
Non-interactively respect the optional OVERRIDE-DATE argument and ignore the option.
magit-commit-reword) ¶Reword the last commit, ignoring staged changes. With a prefix
argument keep the committer date, otherwise change it. The option
magit-commit-reword-override-date can be used to inverse the meaning
of the prefix argument.
Non-interactively respect the optional OVERRIDE-DATE argument and ignore the option.
magit-commit-fixup) ¶Create a fixup commit.
With a prefix argument the target commit has to be confirmed.
Otherwise the commit at point may be used without confirmation
depending on the value of option magit-commit-squash-confirm.
magit-commit-instant-fixup) ¶Create a fixup commit and instantly rebase.
magit-commit-squash) ¶Create a squash commit, without editing the squash message.
With a prefix argument the target commit has to be confirmed.
Otherwise the commit at point may be used without confirmation
depending on the value of option magit-commit-squash-confirm.
magit-commit-instant-squash) ¶Create a squash commit and instantly rebase.
magit-commit-augment) ¶Create a squash commit, editing the squash message.
With a prefix argument the target commit has to be confirmed.
Otherwise the commit at point may be used without confirmation
depending on the value of option magit-commit-squash-confirm.
Whether to ask to stage all unstaged changes when committing and nothing is staged.
Whether the relevant diff is automatically shown when committing.
Whether using magit-commit-extend changes the committer date.
Whether using magit-commit-reword changes the committer date.
Whether the commit targeted by squash and fixup has to be confirmed.
When non-nil then the commit at point (if any) is used as default
choice. Otherwise it has to be confirmed. This option only affects
magit-commit-squash and magit-commit-fixup. The "instant" variants
always require confirmation because making an error while using
those is harder to recover from.
Hook run after creating a commit without the user editing a message.
This hook is run by magit-refresh if this-command is a member
of magit-post-commit-hook-commands. This only includes commands
named magit-commit-* that do not require that the user edits
the commit message in a buffer.
Also see git-commit-post-finish-hook.
Whether to inhibit use of same window when showing diff while committing.
When writing a commit, then a diff of the changes to be committed is automatically shown. The idea is that the diff is shown in a different window of the same frame and for most users that just works. In other words most users can completely ignore this option because its value doesn’t make a difference for them.
However for users who configured Emacs to never create a new window even when the package explicitly tries to do so, then displaying two new buffers necessarily means that the first is immediately replaced by the second. In our case the message buffer is immediately replaced by the diff buffer, which is of course highly undesirable.
A workaround is to suppress this user configuration in this particular case. Users have to explicitly opt-in by toggling this option. We cannot enable the workaround unconditionally because that again causes issues for other users: if the frame is too tiny or the relevant settings too aggressive, then the diff buffer would end up being displayed in a new frame.