Variable: magit-no-confirm

magit-no-confirm is a customizable variable defined in magit-base.el.

Value

(set-and-push)

Documentation

A list of symbols for actions Magit should not confirm, or t.

Many potentially dangerous commands by default 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-cherry-pick Aborting a cherry-pick throws away all
  conflict resolutions which has already been carried out by the
  user.

  abort-revert Aborting a revert throws away all conflict
  resolutions which has already been carried out by the user.

  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 has 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-branch-on-remote Deleting a "remote branch" may mean
  deleting the (local) "remote-tracking" branch only, or also
  removing it from the remote itself. The latter often makes more
  sense because otherwise simply fetching from the remote would
  restore the remote-tracking branch, but doing that can be
  surprising and hard to recover from, so we ask.

  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 popup 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.

Removing modules:

  remove-modules When you remove the working directory of a
  module that does not contain uncommitted changes, then that is
  safer than doing so when there are uncommitted changes and/or
  when you also remove the gitdir. Still, you don't want to do
  that by accident.

  remove-dirty-modules When you remove the working directory of
  a module that contains uncommitted changes, then those changes
  are gone for good. It is better to go to the module, inspect
  these changes and only if appropriate discard them manually.

  trash-module-gitdirs When you remove the gitdir of a module,
  then all unpushed changes are gone for good. It is very easy
  to forget that you have some unfinished work on an unpublished
  feature branch or even in a stash.

  Actually there are some safety precautions in place, that might
  help you out if you make an unwise choice here, but don't count
  on it. In case of emergency, stay calm and check the stash and
  the trash-directory for traces of lost work.

Various:

  stash-apply-3way When a stash cannot be applied using "git
  stash apply", then Magit uses "git apply" instead, possibly
  using the "--3way" argument, which isn't always perfectly
  safe. See also magit-stash-apply.

  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-mode(var)/magit-wip-mode(fun) is enabled then these actions can fairly
  easily be undone: 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.

This variable was added, or its default value changed, in magit version 2.1.0.

Source Code

;; Defined in ~/.emacs.d/elpa/magit-20260411.1452/magit-base.el
(defcustom magit-no-confirm '(set-and-push)
  "A list of symbols for actions Magit should not confirm, or t.

Many potentially dangerous commands by default 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-cherry-pick' Aborting a cherry-pick throws away all
  conflict resolutions which has already been carried out by the
  user.

  `abort-revert' Aborting a revert throws away all conflict
  resolutions which has already been carried out by the user.

  `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 has 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-branch-on-remote' Deleting a \"remote branch\" may mean
  deleting the (local) \"remote-tracking\" branch only, or also
  removing it from the remote itself.  The latter often makes more
  sense because otherwise simply fetching from the remote would
  restore the remote-tracking branch, but doing that can be
  surprising and hard to recover from, so we ask.

  `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 popup 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.

Removing modules:

  `remove-modules' When you remove the working directory of a
  module that does not contain uncommitted changes, then that is
  safer than doing so when there are uncommitted changes and/or
  when you also remove the gitdir.  Still, you don't want to do
  that by accident.

  `remove-dirty-modules' When you remove the working directory of
  a module that contains uncommitted changes, then those changes
  are gone for good.  It is better to go to the module, inspect
  these changes and only if appropriate discard them manually.

  `trash-module-gitdirs' When you remove the gitdir of a module,
  then all unpushed changes are gone for good.  It is very easy
  to forget that you have some unfinished work on an unpublished
  feature branch or even in a stash.

  Actually there are some safety precautions in place, that might
  help you out if you make an unwise choice here, but don't count
  on it.  In case of emergency, stay calm and check the stash and
  the `trash-directory' for traces of lost work.

Various:

  `stash-apply-3way' When a stash cannot be applied using \"git
  stash apply\", then Magit uses \"git apply\" instead, possibly
  using the \"--3way\" argument, which isn't always perfectly
  safe.  See also `magit-stash-apply'.

  `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-mode' is enabled then these actions can fairly
  easily be undone: `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."
  :package-version '(magit . "2.1.0")
  :group 'magit-essentials
  :group 'magit-commands
  :type `(choice (const :tag "Always require confirmation" nil)
                 (const :tag "Never require confirmation" t)
                 (set   :tag "Require confirmation except for"
                        ;; `remove-dirty-modules' and
                        ;; `trash-module-gitdirs' intentionally
                        ;; omitted.
                        ,@magit--confirm-actions)))