6.5.1 Initiating a Commit
Also see the git-commit(1) manpage.
c     (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.
c c     (magit-commit-create)​
Create a new commit on HEAD. With a prefix argument amend to the commit at HEAD instead.
c a     (magit-commit-amend)​
Amend the last commit.
c e     (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.
c w     (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.
c f     (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.
c F     (magit-commit-instant-fixup)​
Create a fixup commit and instantly rebase.
c s     (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.
c S     (magit-commit-instant-squash)​
Create a squash commit and instantly rebase.
c A     (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.
user option magit-commit-ask-to-stage​
Whether to ask to stage all unstaged changes when committing and nothing is staged.
user option magit-commit-show-diff​
Whether the relevant diff is automatically shown when committing.
user option magit-commit-extend-override-date​
Whether using magit-commit-extend changes the committer date.
user option magit-commit-reword-override-date​
Whether using magit-commit-reword changes the committer date.
user option magit-commit-squash-confirm​
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.
user option magit-post-commit-hook​
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-stage-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.
user option magit-commit-diff-inhibit-same-window​
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.