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.
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.
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.
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.
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.
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.
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.
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.
kill-process There 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.
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.