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.
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.
discardDiscarding one or more changes (i.e. hunks or the complete diff for a file) loses that change, obviously.
reverseReverting one or more changes can usually be undone by reverting the reversion.
unstage-all-changesWhen 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.
deleteWhen a file that isn’t yet tracked by Git is deleted, then it is completely lost, not just the last changes. Very dangerous.
trashInstead of deleting a file it can also be move to the system trash. Obviously much less dangerous than deleting it.
Also see option
resurrectA 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.
untrackUntracking a file can be undone by tracking it again.
renameRenaming a file can easily be undone.
reset-bisectAborting (known to Git as "resetting") a bisect operation loses all information collected so far.
abort-rebaseAborting a rebase throws away all already modified commits, but it’s possible to restore those from the reflog.
abort-mergeAborting a merge throws away all conflict resolutions which have already been carried out by the user.
merge-dirtyMerging with a dirty worktree can make it hard to go back to the state before the merge was initiated.
delete-unmerged-branchOnce 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-remoteWhen deleting a branch that was created from a pull-request and if no other branches still exist on that remote, then
magit-branch-deleteoffers 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-stashesDropping 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.
set-and-pushWhen 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
amend-publishedAffects most commands that amend to "HEAD".
rebase-publishedAffects 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-publishedAffects the commands
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
kill-processThere seldom is a reason to kill a process.
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.
magit-wip-before-change-modeis enabled, then the following actions can be undone fairly easily:
unstage-all-changes. If and only if this mode is enabled, then
safe-with-wiphas the same effect as adding all of these symbols individually.