4.5.1 Action Confirmation

By default many actions that could potentially lead to data loss have to be confirmed. This includes many very common actions, so this can quickly become annoying. Many of these actions can be undone and if you have thought about how to undo certain mistakes, then it should be safe to disable confirmation for the respective actions.

The option magit-no-confirm can be used to tell Magit to perform certain actions without the user having to confirm them. Note that while this option can only be used to disable confirmation for a specific set of actions, the next section explains another way of telling Magit to ask fewer questions.

user option magit-no-confirm

The value of this option is a list of symbols, representing actions that do not have to be confirmed by the user before being carried out.

By default many potentially dangerous commands ask the user for confirmation. Each of the below symbols stands for an action which, when invoked unintentionally or without being fully aware of the consequences, could lead to tears. In many cases there are several commands that perform variations of a certain action, so we don’t use the command names but more generic symbols.

• Applying changes:

  • discard Discarding one or more changes (i.e. hunks or the complete diff for a file) loses that change, obviously.
  • reverse Reverting one or more changes can usually be undone by reverting the reversion.
  • stage-all-changes, unstage-all-changes When there are both staged and unstaged changes, then un-/staging everything would destroy that distinction. Of course that also applies when un-/staging a single change, but then less is lost and one does that so often that having to confirm every time would be unacceptable.

• Files:

  • delete When a file that isn’t yet tracked by Git is deleted, then it is completely lost, not just the last changes. Very dangerous.

  • trash Instead of deleting a file it can also be move to the system trash. Obviously much less dangerous than deleting it.

    Also see option magit-delete-by-moving-to-trash.

  • resurrect A deleted file can easily be resurrected by "deleting" the deletion, which is done using the same command that was used to delete the same file in the first place.

  • untrack Untracking a file can be undone by tracking it again.

  • rename Renaming a file can easily be undone.

• Sequences:

  • reset-bisect Aborting (known to Git as "resetting") a bisect operation loses all information collected so far.
  • abort-rebase Aborting a rebase throws away all already modified commits, but it’s possible to restore those from the reflog.
  • abort-merge Aborting a merge throws away all conflict resolutions which have already been carried out by the user.
  • merge-dirty Merging with a dirty worktree can make it hard to go back to the state before the merge was initiated.

• References:

  • delete-unmerged-branch Once a branch has been deleted, it can only be restored using low-level recovery tools provided by Git. And even then the reflog is gone. The user always has to confirm the deletion of a branch by accepting the default choice (or selecting another branch), but when a branch has not been merged yet, also make sure the user is aware of that.
  • delete-pr-remote When deleting a branch that was created from a pull-request and if no other branches still exist on that remote, then magit-branch-delete offers to delete the remote as well. This should be safe because it only happens if no other refs exist in the remotes namespace, and you can recreate the remote if necessary.
  • drop-stashes Dropping a stash is dangerous because Git stores stashes in the reflog. Once a stash is removed, there is no going back without using low-level recovery tools provided by Git. When a single stash is dropped, then the user always has to confirm by accepting the default (or selecting another). This action only concerns the deletion of multiple stashes at once.

• Publishing:

  • set-and-push When pushing to the upstream or the push-remote and that isn’t actually configured yet, then the user can first set the target. If s/he confirms the default too quickly, then s/he might end up pushing to the wrong branch and if the remote repository is configured to disallow fixing such mistakes, then that can be quite embarrassing and annoying.

• Edit published history:

  Without adding these symbols here, you will be warned before editing commits that have already been pushed to one of the branches listed in magit-published-branches.

  • amend-published Affects most commands that amend to "HEAD".
  • rebase-published Affects commands that perform interactive rebases. This includes commands from the commit transient that modify a commit other than "HEAD", namely the various fixup and squash variants.
  • edit-published Affects the commands magit-edit-line-commit and magit-diff-edit-hunk-commit. These two commands make it quite easy to accidentally edit a published commit, so you should think twice before configuring them not to ask for confirmation.

  To disable confirmation completely, add all three symbols here or set magit-published-branches to nil.

• Various:

  • kill-process There seldom is a reason to kill a process.

• Global settings:

  Instead of adding all of the above symbols to the value of this option, you can also set it to the atom ‘t’, which has the same effect as adding all of the above symbols. Doing that most certainly is a bad idea, especially because other symbols might be added in the future. So even if you don’t want to be asked for confirmation for any of these actions, you are still better of adding all of the respective symbols individually.

  When magit-wip-before-change-mode is enabled, then the following actions can be undone fairly easily: discard, reverse, stage-all-changes, and unstage-all-changes. If and only if this mode is enabled, then safe-with-wip has the same effect as adding all of these symbols individually.