path: root/elpa/magit-20200728.45/magit.info-2

This is magit.info, produced by makeinfo version 6.5 from magit.texi.

     Copyright (C) 2015-2020 Jonas Bernoulli <jonas@bernoul.li>

     You can redistribute this document and/or modify it under the terms
     of the GNU General Public License as published by the Free Software
     Foundation, either version 3 of the License, or (at your option)
     any later version.

     This document is distributed in the hope that it will be useful,
     but WITHOUT ANY WARRANTY; without even the implied warranty of
     MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
     General Public License for more details.

INFO-DIR-SECTION Emacs
START-INFO-DIR-ENTRY
* Magit: (magit).       Using Git from Emacs with Magit.
END-INFO-DIR-ENTRY


File: magit.info,  Node: Wip Modes,  Next: Minor Mode for Buffers Visiting Files,  Prev: Common Commands,  Up: Miscellaneous

8.7 Wip Modes
=============

Git keeps *committed* changes around long enough for users to recover
changes they have accidentally deleted.  It does so by not garbage
collecting any committed but no longer referenced objects for a certain
period of time, by default 30 days.

   But Git does *not* keep track of *uncommitted* changes in the working
tree and not even the index (the staging area).  Because Magit makes it
so convenient to modify uncommitted changes, it also makes it easy to
shoot yourself in the foot in the process.

   For that reason Magit provides a global mode that saves *tracked*
files to work-in-progress references after or before certain actions.
(At present untracked files are never saved and for technical reasons
nothing is saved before the first commit has been created).

   Two separate work-in-progress references are used to track the state
of the index and of the working tree: ‘refs/wip/index/<branchref>’ and
‘refs/wip/wtree/<branchref>’, where ‘<branchref>’ is the full ref of the
current branch, e.g.  ‘refs/heads/master’.  When the ‘HEAD’ is detached
then ‘HEAD’ is used in place of ‘<branchref>’.

   Checking out another branch (or detaching ‘HEAD’) causes the use of
different wip refs for subsequent changes.

 -- User Option: magit-wip-mode

     When this mode is enabled, then uncommitted changes are committed
     to dedicated work-in-progress refs whenever appropriate (i.e.  when
     dataloss would be a possibility otherwise).

     Setting this variable directly does not take effect; either use the
     Custom interface to do so or call the respective mode function.

     For historic reasons this mode is implemented on top of four other
     ‘magit-wip-*’ modes, which can also be used individually, if you
     want finer control over when the wip refs are updated; but that is
     discouraged.  See *note Legacy Wip Modes::.

   To view the log for a branch and its wip refs use the commands
‘magit-wip-log’ and ‘magit-wip-log-current’.  You should use ‘--graph’
when using these commands.

 -- Command: magit-wip-log

     This command shows the log for a branch and its wip refs.  With a
     negative prefix argument only the worktree wip ref is shown.

     The absolute numeric value of the prefix argument controls how many
     "branches" of each wip ref are shown.  This is only relevant if the
     value of ‘magit-wip-merge-branch’ is ‘nil’.

 -- Command: magit-wip-log-current

     This command shows the log for the current branch and its wip refs.
     With a negative prefix argument only the worktree wip ref is shown.

     The absolute numeric value of the prefix argument controls how many
     "branches" of each wip ref are shown.  This is only relevant if the
     value of ‘magit-wip-merge-branch’ is ‘nil’.

‘X w’     (‘magit-reset-worktree’)

     This command resets the working tree to some commit read from the
     user and defaulting to the commit at point, while keeping the
     ‘HEAD’ and index as-is.

     This can be used to restore files to the state committed to a wip
     ref.  Note that this will discard any unstaged changes that might
     have existed before invoking this command (but of course only after
     committing that to the working tree wip ref).

   Note that even if you enable ‘magit-wip-mode’ this won’t give you
perfect protection.  The most likely scenario for losing changes despite
the use of ‘magit-wip-mode’ is making a change outside Emacs and then
destroying it also outside Emacs.  In some such a scenario, Magit, being
an Emacs package, didn’t get the opportunity to keep you from shooting
yourself in the foot.

   When you are unsure whether Magit did commit a change to the wip
refs, then you can explicitly request that all changes to all tracked
files are being committed.

‘M-x magit-wip-commit’     (‘magit-wip-commit’)

     This command commits all changes to all tracked files to the index
     and working tree work-in-progress refs.  Like the modes described
     above, it does not commit untracked files, but it does check all
     tracked files for changes.  Use this command when you suspect that
     the modes might have overlooked a change made outside Emacs/Magit.

 -- User Option: magit-wip-namespace

     The namespace used for work-in-progress refs.  It has to end with a
     slash.  The wip refs are named ‘<namespace>index/<branchref>’ and
     ‘<namespace>wtree/<branchref>’.  When snapshots are created while
     the ‘HEAD’ is detached then ‘HEAD’ is used in place of
     ‘<branchref>’.

 -- User Option: magit-wip-mode-lighter

     Mode-line lighter for ‘magit-wip--mode’.

* Menu:

* Wip Graph::
* Legacy Wip Modes::


File: magit.info,  Node: Wip Graph,  Next: Legacy Wip Modes,  Up: Wip Modes

8.7.1 Wip Graph
---------------

 -- User Option: magit-wip-merge-branch

     This option controls whether the current branch is merged into the
     wip refs after a new commit was created on the branch.

     If non-nil and the current branch has new commits, then it is
     merged into the wip ref before creating a new wip commit.  This
     makes it easier to inspect wip history and the wip commits are
     never garbage collected.

     If nil and the current branch has new commits, then the wip ref is
     reset to the tip of the branch before creating a new wip commit.
     With this setting wip commits are eventually garbage collected.

   When ‘magit-wip-merge-branch’ is ‘t’, then the history looks like
this:

       *--*--*--*--*--*       refs/wip/index/refs/heads/master
      /     /     /
     A-----B-----C            refs/heads/master

   When ‘magit-wip-merge-branch’ is ‘nil’, then creating a commit on the
real branch and then making a change causes the wip refs to be recreated
to fork from the new commit.  But the old commits on the wip refs are
not lost.  They are still available from the reflog.  To make it easier
to see when the fork point of a wip ref was changed, an additional
commit with the message "restart autosaving" is created on it (‘xxO’
commits below are such boundary commits).

   Starting with

           BI0---BI1    refs/wip/index/refs/heads/master
          /
     A---B              refs/heads/master
          \
           BW0---BW1    refs/wip/wtree/refs/heads/master

   and committing the staged changes and editing and saving a file would
result in

           BI0---BI1        refs/wip/index/refs/heads/master
          /
     A---B---C              refs/heads/master
          \   \
           \   CW0---CW1    refs/wip/wtree/refs/heads/master
            \
             BW0---BW1      refs/wip/wtree/refs/heads/master@{2}

   The fork-point of the index wip ref is not changed until some change
is being staged.  Likewise just checking out a branch or creating a
commit does not change the fork-point of the working tree wip ref.  The
fork-points are not adjusted until there actually is a change that
should be committed to the respective wip ref.


File: magit.info,  Node: Legacy Wip Modes,  Prev: Wip Graph,  Up: Wip Modes

8.7.2 Legacy Wip Modes
----------------------

It is recommended that you use the mode ‘magit-wip-mode’ (which see) and
ignore the existence of the following modes, which are preserved for
historic reasons.

   Setting the following variables directly does not take effect; either
use the Custom interface to do so or call the respective mode functions.

 -- User Option: magit-wip-after-save-mode

     When this mode is enabled, then saving a buffer that visits a file
     tracked in a Git repository causes its current state to be
     committed to the working tree wip ref for the current branch.

 -- User Option: magit-wip-after-apply-mode

     When this mode is enabled, then applying (i.e.  staging, unstaging,
     discarding, reversing, and regularly applying) a change to a file
     tracked in a Git repository causes its current state to be
     committed to the index and/or working tree wip refs for the current
     branch.

   If you only ever edit files using Emacs and only ever interact with
Git using Magit, then the above two modes should be enough to protect
each and every change from accidental loss.  In practice nobody does
that.  Two additional modes exists that do commit to the wip refs before
making changes that could cause the loss of earlier changes.

 -- User Option: magit-wip-before-change-mode

     When this mode is enabled, then certain commands commit the
     existing changes to the files they are about to make changes to.

 -- User Option: magit-wip-initial-backup-mode

     When this mode is enabled, then the current version of a file is
     committed to the worktree wip ref before the buffer visiting that
     file is saved for the first time since the buffer was created.

     This backs up the same version of the file that ‘backup-buffer’
     would save.  While ‘backup-buffer’ uses a backup file, this mode
     uses the same worktree wip ref as used by the other Magit Wip
     modes.  Like ‘backup-buffer’, it only does this once; unless you
     kill the buffer and visit the file again only one backup will be
     created per Emacs session.

     This mode ignores the variables that affect ‘backup-buffer’ and can
     be used along-side that function, which is recommended because it
     only backs up files that are tracked in a Git repository.

 -- User Option: magit-wip-after-save-local-mode-lighter

     Mode-line lighter for ‘magit-wip-after-save-local-mode’.

 -- User Option: magit-wip-after-apply-mode-lighter

     Mode-line lighter for ‘magit-wip-after-apply-mode’.

 -- User Option: magit-wip-before-change-mode-lighter

     Mode-line lighter for ‘magit-wip-before-change-mode’.

 -- User Option: magit-wip-initial-backup-mode-lighter

     Mode-line lighter for ‘magit-wip-initial-backup-mode’.


File: magit.info,  Node: Minor Mode for Buffers Visiting Files,  Next: Minor Mode for Buffers Visiting Blobs,  Prev: Wip Modes,  Up: Miscellaneous

8.8 Minor Mode for Buffers Visiting Files
=========================================

The minor-mode ‘magit-file-mode’ enables certain Magit features in
file-visiting buffers belonging to a Git repository.  The globalized
variant ‘global-magit-file-mode’ enables the local mode in all such
buffers.  It is enabled by default.  Currently the local mode only
establishes a few key bindings, but this might be extended in the
future.

 -- User Option: global-magit-file-mode

     Whether to establish certain Magit key bindings in all
     file-visiting buffers belonging to any Git repository.  This is
     enabled by default.  This globalized mode turns on the local
     minor-mode ‘magit-file-mode’ in all suitable buffers.

 -- Variable: magit-file-mode-map

     This keymap is used by the local minor-mode ‘magit-file-mode’ and
     establishes the key bindings described below.

     Note that the default binding for ‘magit-file-dispatch’ is very
     cumbersome to use and that we recommend that you add a better
     binding.

     Instead of ‘C-c M-g’ I would have preferred to use ‘C-c g’ because
     (1) it is similar to ‘C-x g’ (the recommended global binding for
     ‘~magit-status’), (2) we cannot use ‘C-c C-g’ because we have been
     recommending that that be bound to ‘magit-dispatch’ for a long
     time, (3) we cannot use ‘C-x C-g’ because that is a convenient way
     of aborting the incomplete key sequence ‘C-x’, and most importantly
     (4) it would make it much easier to type the next key (a suffix
     binding) because most of those are letters.

     For example ‘C-c g b’ is much easier to type than ‘C-c M-g b’.  For
     suffix bindings that use uppercase letters, the default is just
     horrible—having to use e.g.  ‘C-c M-g B’ (‘Control+c Meta+g
     Shift+b’) would drive anyone up the walls (or to Vim).

     However ‘C-c LETTER’ bindings are reserved for users (see *note
     (elisp)Key Binding Conventions::).  Packages are forbidden from
     using those.  Doing so anyway is considered heresy.  Therefore if
     you want a better binding, you have to add it yourself:

          (define-key magit-file-mode-map
            (kbd "C-c g") 'magit-file-dispatch)

   The key bindings shown below assume that you have not improved the
binding for ‘magit-file-dispatch’.

‘C-c M-g’     (‘magit-file-dispatch’)

     This transient prefix command binds the following suffix commands
     and displays them in a temporary buffer until a suffix is invoked.

‘C-c M-g s’     (‘magit-stage-file’)

     Stage all changes to the file being visited in the current buffer.

‘C-c M-g u’     (‘magit-unstage-file’)

     Unstage all changes to the file being visited in the current
     buffer.

‘C-c M-g 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.  See *note Initiating a
     Commit::.

‘C-c M-g D’     (‘magit-diff’)

     This transient prefix command binds several diff suffix commands
     and infix arguments and displays them in a temporary buffer until a
     suffix is invoked.  See *note Diffing::.

     This is the same command that ‘d’ is bound to in Magit buffers.  If
     this command is invoked from a file-visiting buffer, then the
     initial value of the option (‘--’) that limits the diff to certain
     file(s) is set to the visited file.

‘C-c M-g d’     (‘magit-diff-buffer-file’)

     This command shows the diff for the file of blob that the current
     buffer visits.

 -- User Option: magit-diff-buffer-file-locked

     This option controls whether ‘magit-diff-buffer-file’ uses a
     dedicated buffer.  See *note Modes and Buffers::.

‘C-c M-g L’     (‘magit-log’)

     This transient prefix command binds several log suffix commands and
     infix arguments and displays them in a temporary buffer until a
     suffix is invoked.  See *note Logging::.

     This is the same command that ‘l’ is bound to in Magit buffers.  If
     this command is invoked from a file-visiting buffer, then the
     initial value of the option (‘--’) that limits the log to certain
     file(s) is set to the visited file.

‘C-c M-g l’     (‘magit-log-buffer-file’)

     This command shows the log for the file of blob that the current
     buffer visits.  Renames are followed when a prefix argument is used
     or when ‘--follow’ is an active log argument.  When the region is
     active, the log is restricted to the selected line range.

‘C-c M-g t’     (‘magit-log-trace-definition’)

     This command shows the log for the definition at point.

 -- User Option: magit-log-buffer-file-locked

     This option controls whether ‘magit-log-buffer-file’ uses a
     dedicated buffer.  See *note Modes and Buffers::.

‘C-c M-g B’     (‘magit-blame’)

     This transient prefix command binds all blaming suffix commands
     along with the appropriate infix arguments and displays them in a
     temporary buffer until a suffix is invoked.

     For more information about this and the following commands also see
     *note Blaming::.

   In addition to the ‘magit-blame’ sub-transient, the dispatch
transient also binds several blaming suffix commands directly.  See
*note Blaming:: for information about those commands and bindings.

‘C-c M-g e’     (‘magit-edit-line-commit’)

     This command makes the commit editable that added the current line.

     With a prefix argument it makes the commit editable that removes
     the line, if any.  The commit is determined using ‘git blame’ and
     made editable using ‘git rebase --interactive’ if it is reachable
     from ‘HEAD’, or by checking out the commit (or a branch that points
     at it) otherwise.

‘C-c M-g p’     (‘magit-blob-previous’)

     Visit the previous blob which modified the current file.

   There are a few additional commands that operate on a single file but
are not enabled in the file transient command by default:

 -- Command: magit-file-rename

     This command renames a file read from the user.

 -- Command: magit-file-delete

     This command deletes a file read from the user.

 -- Command: magit-file-untrack

     This command untracks a file read from the user.

 -- Command: magit-file-checkout

     This command updates a file in the working tree and index to the
     contents from a revision.  Both the revision and file are read from
     the user.

   To enable them invoke the transient (‘C-c M-g’), enter "edit mode"
(‘C-x l’), set the "transient level" (‘C-x l’ again), enter ‘5’, and
leave edit mode (‘C-g’).  Also see *note (transient)Enabling and
Disabling Suffixes::.


File: magit.info,  Node: Minor Mode for Buffers Visiting Blobs,  Prev: Minor Mode for Buffers Visiting Files,  Up: Miscellaneous

8.9 Minor Mode for Buffers Visiting Blobs
=========================================

The ‘magit-blob-mode’ enables certain Magit features in blob-visiting
buffers.  Such buffers can be created using ‘magit-find-file’ and some
of the commands mentioned below, which also take care of turning on this
minor mode.  Currently this mode only establishes a few key bindings,
but this might be extended.

‘p’     (‘magit-blob-previous’)

     Visit the previous blob which modified the current file.

‘n’     (‘magit-blob-next’)

     Visit the next blob which modified the current file.

‘q’     (‘magit-kill-this-buffer’)

     Kill the current buffer.


File: magit.info,  Node: Customizing,  Next: Plumbing,  Prev: Miscellaneous,  Up: Top

9 Customizing
*************

Both Git and Emacs are highly customizable.  Magit is both a Git
porcelain as well as an Emacs package, so it makes sense to customize it
using both Git variables as well as Emacs options.  However this
flexibility doesn’t come without problems, including but not limited to
the following.

   • Some Git variables automatically have an effect in Magit without
     requiring any explicit support.  Sometimes that is desirable - in
     other cases, it breaks Magit.

     When a certain Git setting breaks Magit but you want to keep using
     that setting on the command line, then that can be accomplished by
     overriding the value for Magit only by appending something like
     ‘("-c" "some.variable=compatible-value")’ to
     ‘magit-git-global-arguments’.

   • Certain settings like ‘fetch.prune=true’ are respected by Magit
     commands (because they simply call the respective Git command) but
     their value is not reflected in the respective transient buffers.
     In this case the ‘--prune’ argument in ‘magit-fetch’ might be
     active or inactive, but that doesn’t keep the Git variable from
     being honored by the suffix commands anyway.  So pruning might
     happen despite the ‘--prune’ arguments being displayed in a way
     that seems to indicate that no pruning will happen.

   I intend to address these and similar issues in a future release.

* Menu:

* Per-Repository Configuration::
* Essential Settings::


File: magit.info,  Node: Per-Repository Configuration,  Next: Essential Settings,  Up: Customizing

9.1 Per-Repository Configuration
================================

Magit can be configured on a per-repository level using both Git
variables as well as Emacs options.

   To set a Git variable for one repository only, simply set it in
‘/path/to/repo/.git/config’ instead of ‘$HOME/.gitconfig’ or
‘/etc/gitconfig’.  See *note (gitman)git-config::.

   Similarly, Emacs options can be set for one repository only by
editing ‘/path/to/repo/.dir-locals.el’.  See *note (emacs)Directory
Variables::.  For example to disable automatic refreshes of
file-visiting buffers in just one huge repository use this:

   • ‘/path/to/huge/repo/.dir-locals.el’

          ((nil . ((magit-refresh-buffers . nil))))

   It might only be costly to insert certain information into Magit
buffers for repositories that are exceptionally large, in which case you
can disable the respective section inserters just for that repository:

   • ‘/path/to/tag/invested/repo/.dir-locals.el’

          ((magit-status-mode
            . ((eval . (magit-disable-section-inserter 'magit-insert-tags-header)))))

 -- Function: magit-disable-section-inserter fn

     This function disables the section inserter FN in the current
     repository.  It is only intended for use in ‘.dir-locals.el’ and
     ‘.dir-locals-2.el’.

   If you want to apply the same settings to several, but not all,
repositories then keeping the repository-local config files in sync
would quickly become annoying.  To avoid that you can create config
files for certain classes of repositories (e.g.  "huge repositories")
and then include those files in the per-repository config files.  For
example:

   • ‘/path/to/huge/repo/.git/config’

          [include]
                  path = /path/to/huge-gitconfig

   • ‘/path/to/huge-gitconfig’

          [status]
                  showUntrackedFiles = no

   • ‘$HOME/.emacs.d/init.el’

          (dir-locals-set-class-variables 'huge-git-repository
             '((nil . ((magit-refresh-buffers . nil)))))

          (dir-locals-set-directory-class
             "/path/to/huge/repo/" 'huge-git-repository)


File: magit.info,  Node: Essential Settings,  Prev: Per-Repository Configuration,  Up: Customizing

9.2 Essential Settings
======================

The next two sections list and discuss several variables that many users
might want to customize, for safety and/or performance reasons.

* Menu:

* Safety::
* Performance::


File: magit.info,  Node: Safety,  Next: Performance,  Up: Essential Settings

9.2.1 Safety
------------

This section discusses various variables that you might want to change
(or *not* change) for safety reasons.

   Git keeps *committed* changes around long enough for users to recover
changes they have accidentally been deleted.  It does not do the same
for *uncommitted* changes in the working tree and not even the index
(the staging area).  Because Magit makes it so easy to modify
uncommitted changes, it also makes it easy to shoot yourself in the foot
in the process.  For that reason Magit provides three global modes that
save *tracked* files to work-in-progress references after or before
certain actions.  See *note Wip Modes::.

   These modes are not enabled by default because of performance
concerns.  Instead a lot of potentially destructive commands require
confirmation every time they are used.  In many cases this can be
disabled by adding a symbol to ‘magit-no-confirm’ (see *note Completion
and Confirmation::).  If you enable the various wip modes then you
should add ‘safe-with-wip’ to this list.

   Similarly it isn’t necessary to require confirmation before moving a
file to the system trash - if you trashed a file by mistake then you can
recover it from there.  Option ‘magit-delete-by-moving-to-trash’
controls whether the system trash is used, which is the case by default.
Nevertheless, ‘trash’ isn’t a member of ‘magit-no-confirm’ - you might
want to change that.

   By default buffers visiting files are automatically reverted when the
visited file changes on disk.  This isn’t as risky as it might seem, but
to make an informed decision you should see *note Risk of Reverting
Automatically::.


File: magit.info,  Node: Performance,  Prev: Safety,  Up: Essential Settings

9.2.2 Performance
-----------------

After Magit has run ‘git’ for side-effects, it also refreshes the
current Magit buffer and the respective status buffer.  This is
necessary because otherwise outdated information might be displayed
without the user noticing.  Magit buffers are updated by recreating
their content from scratch, which makes updating simpler and less
error-prone, but also more costly.  Keeping it simple and just
re-creating everything from scratch is an old design decision and
departing from that will require major refactoring.

   I plan to do that in time for the next major release.  I also intend
to create logs and diffs asynchronously, which should also help a lot
but also requires major refactoring.

   Meanwhile you can tell Magit to only automatically refresh the
current Magit buffer, but not the status buffer.  If you do that, then
the status buffer is only refreshed automatically if it is the current
buffer.

     (setq magit-refresh-status-buffer nil)

   You should also check whether any third-party packages have added
anything to ‘magit-refresh-buffer-hook’, ‘magit-status-refresh-hook’,
‘magit-pre-refresh-hook’, and ‘magit-post-refresh-hook’.  If so, then
check whether those additions impact performance significantly.

   Magit can be told to refresh buffers verbosely using ‘M-x
magit-toggle-verbose-refresh’.  Enabling this helps figuring out which
sections are bottlenecks.  The additional output can be found in the
‘*Messages*’ buffer.

   Magit also reverts buffers for visited files located inside the
current repository when the visited file changes on disk.  That is
implemented on top of ‘auto-revert-mode’ from the built-in library
‘autorevert’.  To figure out whether that impacts performance, check
whether performance is significantly worse, when many buffers exist
and/or when some buffers visit files using TRAMP.  If so, then this
should help.

     (setq auto-revert-buffer-list-filter
           'magit-auto-revert-repository-buffer-p)

   For alternative approaches see *note Automatic Reverting of
File-Visiting Buffers::.

   If you have enabled any features that are disabled by default, then
you should check whether they impact performance significantly.  It’s
likely that they were not enabled by default because it is known that
they reduce performance at least in large repositories.

   If performance is only slow inside certain unusually large
repositories, then you might want to disable certain features on a
per-repository or per-repository-class basis only.  See *note
Per-Repository Configuration::.  For example it takes a long time to
determine the next and current tag in repository with exceptional
numbers of tags.  It would therefore be a good idea to disable
‘magit-insert-tags-headers’, as explained at the mentioned node.

* Menu:

* Microsoft Windows Performance::
* MacOS Performance::

Log Performance
...............

When showing logs, Magit limits the number of commits initially shown in
the hope that this avoids unnecessary work.  When using ‘--graph’ is
used, then this unfortunately does not have the desired effect for large
histories.  Junio, Git’s maintainer, said on the git mailing list
(<http://www.spinics.net/lists/git/msg232230.html>): "‘--graph’ wants to
compute the whole history and the max-count only affects the output
phase after ‘--graph’ does its computation".

   In other words, it’s not that Git is slow at outputting the
differences, or that Magit is slow at parsing the output - the problem
is that Git first goes outside and has a smoke.

   We actually work around this issue by limiting the number of commits
not only by using ‘-<N>’ but by also using a range.  But unfortunately
that’s not always possible.

   When more than a few thousand commits are shown, then the use of
‘--graph’ can slow things down.

   Using ‘--color --graph’ is even slower.  Magit uses code that is part
of Emacs to turn control characters into faces.  That code is pretty
slow and this is quite noticeable when showing a log with many branches
and merges.  For that reason ‘--color’ is not enabled by default
anymore.  Consider leaving it at that.

Diff Performance
................

If diffs are slow, then consider turning off some optional diff features
by setting all or some of the following variables to ‘nil’:
‘magit-diff-highlight-indentation’, ‘magit-diff-highlight-trailing’,
‘magit-diff-paint-whitespace’, ‘magit-diff-highlight-hunk-body’, and
‘magit-diff-refine-hunk’.

   When showing a commit instead of some arbitrary diff, then some
additional information is displayed.  Calculating this information can
be quite expensive given certain circumstances.  If looking at a commit
using ‘magit-revision-mode’ takes considerably more time than looking at
the same commit in ‘magit-diff-mode’, then consider setting
‘magit-revision-insert-related-refs’ to ‘nil’.

   When you are often confronted with diffs that contain deleted files,
then you might want to enable the ‘--irreversible-delete’ argument.  If
you do that then diffs still show that a file was deleted but without
also showing the complete deleted content of the file.  This argument is
not available by default, see *note (transient)Enabling and Disabling
Suffixes::.  Once you have done that you should enable it and save that
setting, see *note (transient)Saving Values::.  You should do this in
both the diff (‘d’) and the diff refresh (‘D’) transient popups.

Refs Buffer Performance
.......................

When refreshing the "references buffer" is slow, then that’s usually
because several hundred refs are being displayed.  The best way to
address that is to display fewer refs, obviously.

   If you are not, or only mildly, interested in seeing the list of
tags, then start by not displaying them:

     (remove-hook 'magit-refs-sections-hook 'magit-insert-tags)

   Then you should also make sure that the listed remote branches
actually all exist.  You can do so by pruning branches which no longer
exist using ‘f-pa’.

Committing Performance
......................

When you initiate a commit, then Magit by default automatically shows a
diff of the changes you are about to commit.  For large commits this can
take a long time, which is especially distracting when you are
committing large amounts of generated data which you don’t actually
intend to inspect before committing.  This behavior can be turned off
using:

     (remove-hook 'server-switch-hook 'magit-commit-diff)

   Then you can type ‘C-c C-d’ to show the diff when you actually want
to see it, but only then.  Alternatively you can leave the hook alone
and just type ‘C-g’ in those cases when it takes too long to generate
the diff.  If you do that, then you will end up with a broken diff
buffer, but doing it this way has the advantage that you usually get to
see the diff, which is useful because it increases the odds that you
spot potential issues.


File: magit.info,  Node: Microsoft Windows Performance,  Next: MacOS Performance,  Up: Performance

Microsoft Windows Performance
.............................

In order to update the status buffer, ‘git’ has to be run a few dozen
times.  That is problematic on Microsoft Windows, because that operating
system is exceptionally slow at starting processes.  Sadly this is an
issue that can only be fixed by Microsoft itself, and they don’t appear
to be particularly interested in doing so.

   Beside the subprocess issue, there are also other Windows-specific
performance issues.  Some of these have workarounds.  The maintainers of
"Git for Windows" try to improve performance on Windows.  Always use the
latest release in order to benefit from the latest performance tweaks.
Magit too tries to work around some Windows-specific issues.

   According to some sources, setting the following Git variables can
also help.

     git config --global core.preloadindex true   # default since v2.1
     git config --global core.fscache true        # default since v2.8
     git config --global gc.auto 256

   You should also check whether an anti-virus program is affecting
performance.


File: magit.info,  Node: MacOS Performance,  Prev: Microsoft Windows Performance,  Up: Performance

MacOS Performance
.................

Before Emacs 26.1 child processes were created using ‘fork’ on macOS.
That needlessly copied GUI resources, which is expensive.  The result
was that forking took about 30 times as long on Darwin than on Linux,
and because Magit starts many ‘git’ processes that made quite a
difference.

   So make sure that you are using at least Emacs 26.1, in which case
the faster ‘vfork’ will be used.  (The creation of child processes still
takes about twice as long on Darwin compared to Linux.)  See (1) for
more information.

   On Catalina, and potentially other macOS releases, there may be a
performance problem where any action takes 20 times longer on Darwin
than on Linux.  This can be fixed by setting ‘magit-git-executable’ to
the absolute path of the ‘git’ executable, instead of relying on
resolving the ‘$PATH’.

   ---------- Footnotes ----------

   (1) 
<https://lists.gnu.org/archive/html/bug-gnu-emacs/2017-04/msg00201.html>


File: magit.info,  Node: Plumbing,  Next: FAQ,  Prev: Customizing,  Up: Top

10 Plumbing
***********

The following sections describe how to use several of Magit’s core
abstractions to extend Magit itself or implement a separate extension.

   A few of the low-level features used by Magit have been factored out
into separate libraries/packages, so that they can be used by other
packages, without having to depend on Magit.  See *note
(with-editor)Top:: for information about ‘with-editor’.  ‘transient’
doesn’t have a manual yet.

   If you are trying to find an unused key that you can bind to a
command provided by your own Magit extension, then checkout
<https://github.com/magit/magit/wiki/Plugin-Dispatch-Key-Registry>.

* Menu:

* Calling Git::
* Section Plumbing::
* Refreshing Buffers::
* Conventions::


File: magit.info,  Node: Calling Git,  Next: Section Plumbing,  Up: Plumbing

10.1 Calling Git
================

Magit provides many specialized functions for calling Git.  All of these
functions are defined in either ‘magit-git.el’ or ‘magit-process.el’ and
have one of the prefixes ‘magit-run-’, ‘magit-call-’, ‘magit-start-’, or
‘magit-git-’ (which is also used for other things).

   All of these functions accept an indefinite number of arguments,
which are strings that specify command line arguments for Git (or in
some cases an arbitrary executable).  These arguments are flattened
before being passed on to the executable; so instead of strings they can
also be lists of strings and arguments that are ‘nil’ are silently
dropped.  Some of these functions also require a single mandatory
argument before these command line arguments.

   Roughly speaking, these functions run Git either to get some value or
for side-effects.  The functions that return a value are useful to
collect the information necessary to populate a Magit buffer, while the
others are used to implement Magit commands.

   The functions in the value-only group always run synchronously, and
they never trigger a refresh.  The function in the side-effect group can
be further divided into subgroups depending on whether they run Git
synchronously or asynchronously, and depending on whether they trigger a
refresh when the executable has finished.

* Menu:

* Getting a Value from Git::
* Calling Git for Effect::


File: magit.info,  Node: Getting a Value from Git,  Next: Calling Git for Effect,  Up: Calling Git

10.1.1 Getting a Value from Git
-------------------------------

These functions run Git in order to get a value, an exit status, or
output.  Of course you could also use them to run Git commands that have
side-effects, but that should be avoided.

 -- Function: magit-git-exit-code &rest args

     Executes git with ARGS and returns its exit code.

 -- Function: magit-git-success &rest args

     Executes git with ARGS and returns ‘t’ if the exit code is ‘0’,
     ‘nil’ otherwise.

 -- Function: magit-git-failure &rest args

     Executes git with ARGS and returns ‘t’ if the exit code is ‘1’,
     ‘nil’ otherwise.

 -- Function: magit-git-true &rest args

     Executes git with ARGS and returns ‘t’ if the first line printed by
     git is the string "true", ‘nil’ otherwise.

 -- Function: magit-git-false &rest args

     Executes git with ARGS and returns ‘t’ if the first line printed by
     git is the string "false", ‘nil’ otherwise.

 -- Function: magit-git-insert &rest args

     Executes git with ARGS and inserts its output at point.

 -- Function: magit-git-string &rest args

     Executes git with ARGS and returns the first line of its output.
     If there is no output or if it begins with a newline character,
     then this returns ‘nil’.

 -- Function: magit-git-lines &rest args

     Executes git with ARGS and returns its output as a list of lines.
     Empty lines anywhere in the output are omitted.

 -- Function: magit-git-items &rest args

     Executes git with ARGS and returns its null-separated output as a
     list.  Empty items anywhere in the output are omitted.

     If the value of option ‘magit-git-debug’ is non-nil and git exits
     with a non-zero exit status, then warn about that in the echo area
     and add a section containing git’s standard error in the current
     repository’s process buffer.

   If an error occurs when using one of the above functions, then that
is usually due to a bug, i.e.  using an argument which is not actually
supported.  Such errors are usually not reported, but when they occur we
need to be able to debug them.

 -- User Option: magit-git-debug

     Whether to report errors that occur when using ‘magit-git-insert’,
     ‘magit-git-string’, ‘magit-git-lines’, or ‘magit-git-items’.  This
     does not actually raise an error.  Instead a message is shown in
     the echo area, and git’s standard error is insert into a new
     section in the current repository’s process buffer.

 -- Function: magit-git-str &rest args

     This is a variant of ‘magit-git-string’ that ignores the option
     ‘magit-git-debug’.  It is mainly intended to be used while handling
     errors in functions that do respect that option.  Using such a
     function while handing an error could cause yet another error and
     therefore lead to an infinite recursion.  You probably won’t ever
     need to use this function.


File: magit.info,  Node: Calling Git for Effect,  Prev: Getting a Value from Git,  Up: Calling Git

10.1.2 Calling Git for Effect
-----------------------------

These functions are used to run git to produce some effect.  Most Magit
commands that actually run git do so by using such a function.

   Because we do not need to consume git’s output when using these
functions, their output is instead logged into a per-repository buffer,
which can be shown using ‘$’ from a Magit buffer or ‘M-x magit-process’
elsewhere.

   These functions can have an effect in two distinct ways.  Firstly,
running git may change something, i.e.  create or push a new commit.
Secondly, that change may require that Magit buffers are refreshed to
reflect the changed state of the repository.  But refreshing isn’t
always desirable, so only some of these functions do perform such a
refresh after git has returned.

   Sometimes it is useful to run git asynchronously.  For example, when
the user has just initiated a push, then there is no reason to make her
wait until that has completed.  In other cases it makes sense to wait
for git to complete before letting the user do something else.  For
example after staging a change it is useful to wait until after the
refresh because that also automatically moves to the next change.

 -- Function: magit-call-git &rest args

     Calls git synchronously with ARGS.

 -- Function: magit-call-process program &rest args

     Calls PROGRAM synchronously with ARGS.

 -- Function: magit-run-git &rest args

     Calls git synchronously with ARGS and then refreshes.

 -- Function: magit-run-git-with-input input &rest args

     Calls git synchronously with ARGS and sends it INPUT on standard
     input.

     INPUT should be a buffer or the name of an existing buffer.  The
     content of that buffer is used as the process’s standard input.
     After the process returns a refresh is performed.

     As a special case, INPUT may also be nil.  In that case the content
     of the current buffer is used as standard input and *no* refresh is
     performed.

     This function actually runs git asynchronously.  But then it waits
     for the process to return, so the function itself is synchronous.

 -- Function: magit-run-git-with-logfile file &rest args

     Calls git synchronously with ARGS.  The process’s output is saved
     in FILE.  This is rarely useful and so this function might be
     removed in the future.

     This function actually runs git asynchronously.  But then it waits
     for the process to return, so the function itself is synchronous.

 -- Function: magit-git &rest args

     Calls git synchronously with ARGS for side-effects only.  This
     function does not refresh the buffer.

 -- Function: magit-git-wash washer &rest args

     Execute Git with ARGS, inserting washed output at point.  Actually
     first insert the raw output at point.  If there is no output call
     ‘magit-cancel-section’.  Otherwise temporarily narrow the buffer to
     the inserted text, move to its beginning, and then call function
     WASHER with ARGS as its sole argument.

   And now for the asynchronous variants.

 -- Function: magit-run-git-async &rest args

     Start Git, prepare for refresh, and return the process object.
     ARGS is flattened and then used as arguments to Git.

     Display the command line arguments in the echo area.

     After Git returns some buffers are refreshed: the buffer that was
     current when this function was called (if it is a Magit buffer and
     still alive), as well as the respective Magit status buffer.
     Unmodified buffers visiting files that are tracked in the current
     repository are reverted if ‘magit-revert-buffers’ is non-nil.

 -- Function: magit-run-git-with-editor &rest args

     Export GIT_EDITOR and start Git.  Also prepare for refresh and
     return the process object.  ARGS is flattened and then used as
     arguments to Git.

     Display the command line arguments in the echo area.

     After Git returns some buffers are refreshed: the buffer that was
     current when this function was called (if it is a Magit buffer and
     still alive), as well as the respective Magit status buffer.

 -- Function: magit-start-git &rest args

     Start Git, prepare for refresh, and return the process object.

     If INPUT is non-nil, it has to be a buffer or the name of an
     existing buffer.  The buffer content becomes the processes standard
     input.

     Option ‘magit-git-executable’ specifies the Git executable and
     option ‘magit-git-global-arguments’ specifies constant arguments.
     The remaining arguments ARGS specify arguments to Git.  They are
     flattened before use.

     After Git returns, some buffers are refreshed: the buffer that was
     current when this function was called (if it is a Magit buffer and
     still alive), as well as the respective Magit status buffer.
     Unmodified buffers visiting files that are tracked in the current
     repository are reverted if ‘magit-revert-buffers’ is non-nil.

 -- Function: magit-start-process &rest args

     Start PROGRAM, prepare for refresh, and return the process object.

     If optional argument INPUT is non-nil, it has to be a buffer or the
     name of an existing buffer.  The buffer content becomes the
     processes standard input.

     The process is started using ‘start-file-process’ and then setup to
     use the sentinel ‘magit-process-sentinel’ and the filter
     ‘magit-process-filter’.  Information required by these functions is
     stored in the process object.  When this function returns the
     process has not started to run yet so it is possible to override
     the sentinel and filter.

     After the process returns, ‘magit-process-sentinel’ refreshes the
     buffer that was current when ‘magit-start-process’ was called (if
     it is a Magit buffer and still alive), as well as the respective
     Magit status buffer.  Unmodified buffers visiting files that are
     tracked in the current repository are reverted if
     ‘magit-revert-buffers’ is non-nil.

 -- Variable: magit-this-process

     The child process which is about to start.  This can be used to
     change the filter and sentinel.

 -- Variable: magit-process-raise-error

     When this is non-nil, then ‘magit-process-sentinel’ raises an error
     if git exits with a non-zero exit status.  For debugging purposes.


File: magit.info,  Node: Section Plumbing,  Next: Refreshing Buffers,  Prev: Calling Git,  Up: Plumbing

10.2 Section Plumbing
=====================

* Menu:

* Creating Sections::
* Section Selection::
* Matching Sections::


File: magit.info,  Node: Creating Sections,  Next: Section Selection,  Up: Section Plumbing

10.2.1 Creating Sections
------------------------

 -- Macro: magit-insert-section &rest args

     Insert a section at point.

     TYPE is the section type, a symbol.  Many commands that act on the
     current section behave differently depending on that type.  Also if
     a variable ‘magit-TYPE-section-map’ exists, then use that as the
     text-property ‘keymap’ of all text belonging to the section (but
     this may be overwritten in subsections).  TYPE can also have the
     form ‘(eval FORM)’ in which case FORM is evaluated at runtime.

     Optional VALUE is the value of the section, usually a string that
     is required when acting on the section.

     When optional HIDE is non-nil collapse the section body by default,
     i.e.  when first creating the section, but not when refreshing the
     buffer.  Otherwise, expand it by default.  This can be overwritten
     using ‘magit-section-set-visibility-hook’.  When a section is
     recreated during a refresh, then the visibility of predecessor is
     inherited and HIDE is ignored (but the hook is still honored).

     BODY is any number of forms that actually insert the section’s
     heading and body.  Optional NAME, if specified, has to be a symbol,
     which is then bound to the struct of the section being inserted.

     Before BODY is evaluated the ‘start’ of the section object is set
     to the value of ‘point’ and after BODY was evaluated its ‘end’ is
     set to the new value of ‘point’; BODY is responsible for moving
     ‘point’ forward.

     If it turns out inside BODY that the section is empty, then
     ‘magit-cancel-section’ can be used to abort and remove all traces
     of the partially inserted section.  This can happen when creating a
     section by washing Git’s output and Git didn’t actually output
     anything this time around.

 -- Function: magit-insert-heading &rest args

     Insert the heading for the section currently being inserted.

     This function should only be used inside ‘magit-insert-section’.

     When called without any arguments, then just set the ‘content’ slot
     of the object representing the section being inserted to a marker
     at ‘point’.  The section should only contain a single line when
     this function is used like this.

     When called with arguments ARGS, which have to be strings, then
     insert those strings at point.  The section should not contain any
     text before this happens and afterwards it should again only
     contain a single line.  If the ‘face’ property is set anywhere
     inside any of these strings, then insert all of them unchanged.
     Otherwise use the ‘magit-section-heading’ face for all inserted
     text.

     The ‘content’ property of the section struct is the end of the
     heading (which lasts from ‘start’ to ‘content’) and the beginning
     of the body (which lasts from ‘content’ to ‘end’).  If the value of
     ‘content’ is nil, then the section has no heading and its body
     cannot be collapsed.  If a section does have a heading then its
     height must be exactly one line, including a trailing newline
     character.  This isn’t enforced; you are responsible for getting it
     right.  The only exception is that this function does insert a
     newline character if necessary.

 -- Function: magit-cancel-section

     Cancel the section currently being inserted.  This exits the
     innermost call to ‘magit-insert-section’ and removes all traces of
     what has already happened inside that call.

 -- Function: magit-define-section-jumper sym title &optional value

     Define an interactive function to go to section SYM.  TITLE is the
     displayed title of the section.


File: magit.info,  Node: Section Selection,  Next: Matching Sections,  Prev: Creating Sections,  Up: Section Plumbing

10.2.2 Section Selection
------------------------

 -- Function: magit-current-section

     Return the section at point.

 -- Function: magit-region-sections &optional condition multiple

     Return a list of the selected sections.

     When the region is active and constitutes a valid section
     selection, then return a list of all selected sections.  This is
     the case when the region begins in the heading of a section and
     ends in the heading of the same section or in that of a sibling
     section.  If optional MULTIPLE is non-nil, then the region cannot
     begin and end in the same section.

     When the selection is not valid, then return nil.  In this case,
     most commands that can act on the selected sections will instead
     act on the section at point.

     When the region looks like it would in any other buffer then the
     selection is invalid.  When the selection is valid then the region
     uses the ‘magit-section-highlight’ face.  This does not apply to
     diffs where things get a bit more complicated, but even here if the
     region looks like it usually does, then that’s not a valid
     selection as far as this function is concerned.

     If optional CONDITION is non-nil, then the selection not only has
     to be valid; all selected sections additionally have to match
     CONDITION, or nil is returned.  See ‘magit-section-match’ for the
     forms CONDITION can take.

 -- Function: magit-region-values &optional condition multiple

     Return a list of the values of the selected sections.

     Return the values that themselves would be returned by
     ‘magit-region-sections’ (which see).


File: magit.info,  Node: Matching Sections,  Prev: Section Selection,  Up: Section Plumbing

10.2.3 Matching Sections
------------------------

‘M-x magit-describe-section-briefly’     (‘magit-describe-section-briefly’)

     Show information about the section at point.  This command is
     intended for debugging purposes.

 -- Function: magit-section-ident section

     Return an unique identifier for SECTION.  The return value has the
     form ‘((TYPE . VALUE)...)’.

 -- Function: magit-get-section ident &optional root

     Return the section identified by IDENT.  IDENT has to be a list as
     returned by ‘magit-section-ident’.

 -- Function: magit-section-match condition &optional section

     Return ‘t’ if SECTION matches CONDITION.  SECTION defaults to the
     section at point.  If SECTION is not specified and there also is no
     section at point, then return ‘nil’.

     CONDITION can take the following forms:
        • ‘(CONDITION...)’

          matches if any of the CONDITIONs matches.

        • ‘[CLASS...]’

          matches if the section’s class is the same as the first CLASS
          or a subclass of that; the section’s parent class matches the
          second CLASS; and so on.

        • ‘[* CLASS...]’

          matches sections that match ‘[CLASS...]’ and also recursively
          all their child sections.

        • ‘CLASS’

          matches if the section’s class is the same as CLASS or a
          subclass of that; regardless of the classes of the parent
          sections.

     Each CLASS should be a class symbol, identifying a class that
     derives from ‘magit-section’.  For backward compatibility CLASS can
     also be a "type symbol".  A section matches such a symbol if the
     value of its ‘type’ slot is ‘eq’.  If a type symbol has an entry in
     ‘magit--section-type-alist’, then a section also matches that type
     if its class is a subclass of the class that corresponds to the
     type as per that alist.

     Note that it is not necessary to specify the complete section
     lineage as printed by ‘magit-describe-section-briefly’, unless of
     course you want to be that precise.

 -- Function: magit-section-value-if condition &optional section

     If the section at point matches CONDITION, then return its value.

     If optional SECTION is non-nil then test whether that matches
     instead.  If there is no section at point and SECTION is nil, then
     return nil.  If the section does not match, then return nil.

     See ‘magit-section-match’ for the forms CONDITION can take.

 -- Function: magit-section-case &rest clauses

     Choose among clauses on the type of the section at point.

     Each clause looks like (CONDITION BODY...).  The type of the
     section is compared against each CONDITION; the BODY forms of the
     first match are evaluated sequentially and the value of the last
     form is returned.  Inside BODY the symbol ‘it’ is bound to the
     section at point.  If no clause succeeds or if there is no section
     at point return nil.

     See ‘magit-section-match’ for the forms CONDITION can take.
     Additionally a CONDITION of t is allowed in the final clause and
     matches if no other CONDITION match, even if there is no section at
     point.

 -- Variable: magit-root-section

     The root section in the current buffer.  All other sections are
     descendants of this section.  The value of this variable is set by
     ‘magit-insert-section’ and you should never modify it.

   For diff related sections a few additional tools exist.

 -- Function: magit-diff-type &optional section

     Return the diff type of SECTION.

     The returned type is one of the symbols ‘staged’, ‘unstaged’,
     ‘committed’, or ‘undefined’.  This type serves a similar purpose as
     the general type common to all sections (which is stored in the
     ‘type’ slot of the corresponding ‘magit-section’ struct) but takes
     additional information into account.  When the SECTION isn’t
     related to diffs and the buffer containing it also isn’t a
     diff-only buffer, then return nil.

     Currently the type can also be one of ‘tracked’ and ‘untracked’,
     but these values are not handled explicitly in every place they
     should be.  A possible fix could be to just return nil here.

     The section has to be a ‘diff’ or ‘hunk’ section, or a section
     whose children are of type ‘diff’.  If optional SECTION is nil,
     return the diff type for the current section.  In buffers whose
     major mode is ‘magit-diff-mode’ SECTION is ignored and the type is
     determined using other means.  In ‘magit-revision-mode’ buffers the
     type is always ‘committed’.

 -- Function: magit-diff-scope &optional section strict

     Return the diff scope of SECTION or the selected section(s).

     A diff’s "scope" describes what part of a diff is selected, it is a
     symbol, one of ‘region’, ‘hunk’, ‘hunks’, ‘file’, ‘files’, or
     ‘list’.  Do not confuse this with the diff "type", as returned by
     ‘magit-diff-type’.

     If optional SECTION is non-nil, then return the scope of that,
     ignoring the sections selected by the region.  Otherwise return the
     scope of the current section, or if the region is active and
     selects a valid group of diff related sections, the type of these
     sections, i.e.  ‘hunks’ or ‘files’.  If SECTION (or if the current
     section that is nil) is a ‘hunk’ section and the region starts and
     ends inside the body of a that section, then the type is ‘region’.

     If optional STRICT is non-nil then return nil if the diff type of
     the section at point is ‘untracked’ or the section at point is not
     actually a ‘diff’ but a ‘diffstat’ section.


File: magit.info,  Node: Refreshing Buffers,  Next: Conventions,  Prev: Section Plumbing,  Up: Plumbing

10.3 Refreshing Buffers
=======================

All commands that create a new Magit buffer or change what is being
displayed in an existing buffer do so by calling ‘magit-mode-setup’.
Among other things, that function sets the buffer local values of
‘default-directory’ (to the top-level of the repository),
‘magit-refresh-function’, and ‘magit-refresh-args’.

   Buffers are refreshed by calling the function that is the local value
of ‘magit-refresh-function’ (a function named ‘magit-*-refresh-buffer’,
where ‘*’ may be something like ‘diff’) with the value of
‘magit-refresh-args’ as arguments.

 -- Macro: magit-mode-setup buffer switch-func mode refresh-func
          &optional refresh-args

     This function displays and selects BUFFER, turns on MODE, and
     refreshes a first time.

     This function displays and optionally selects BUFFER by calling
     ‘magit-mode-display-buffer’ with BUFFER, MODE and SWITCH-FUNC as
     arguments.  Then it sets the local value of
     ‘magit-refresh-function’ to REFRESH-FUNC and that of
     ‘magit-refresh-args’ to REFRESH-ARGS.  Finally it creates the
     buffer content by calling REFRESH-FUNC with REFRESH-ARGS as
     arguments.

     All arguments are evaluated before switching to BUFFER.

 -- Function: magit-mode-display-buffer buffer mode &optional
          switch-function

     This function display BUFFER in some window and select it.  BUFFER
     may be a buffer or a string, the name of a buffer.  The buffer is
     returned.

     Unless BUFFER is already displayed in the selected frame, store the
     previous window configuration as a buffer local value, so that it
     can later be restored by ‘magit-mode-bury-buffer’.

     The buffer is displayed and selected using SWITCH-FUNCTION.  If
     that is ‘nil’ then ‘pop-to-buffer’ is used if the current buffer’s
     major mode derives from ‘magit-mode’.  Otherwise ‘switch-to-buffer’
     is used.

 -- Variable: magit-refresh-function

     The value of this buffer-local variable is the function used to
     refresh the current buffer.  It is called with ‘magit-refresh-args’
     as arguments.

 -- Variable: magit-refresh-args

     The list of arguments used by ‘magit-refresh-function’ to refresh
     the current buffer.  ‘magit-refresh-function’ is called with these
     arguments.

     The value is usually set using ‘magit-mode-setup’, but in some
     cases it’s also useful to provide commands that can change the
     value.  For example, the ‘magit-diff-refresh’ transient can be used
     to change any of the arguments used to display the diff, without
     having to specify again which differences should be shown, but
     ‘magit-diff-more-context’, ‘magit-diff-less-context’ and
     ‘magit-diff-default-context’ change just the ‘-U<N>’ argument.  In
     both case this is done by changing the value of this variable and
     then calling this ‘magit-refresh-function’.


File: magit.info,  Node: Conventions,  Prev: Refreshing Buffers,  Up: Plumbing

10.4 Conventions
================

Also see *note Completion and Confirmation::.

* Menu:

* Theming Faces::


File: magit.info,  Node: Theming Faces,  Up: Conventions

10.4.1 Theming Faces
--------------------

The default theme uses blue for local branches, green for remote
branches, and goldenrod (brownish yellow) for tags.  When creating a new
theme, you should probably follow that example.  If your theme already
uses other colors, then stick to that.

   In older releases these reference faces used to have a background
color and a box around them.  The basic default faces no longer do so,
to make Magit buffers much less noisy, and you should follow that
example at least with regards to boxes.  (Boxes were used in the past to
work around a conflict between the highlighting overlay and text
property backgrounds.  That’s no longer necessary because highlighting
no longer causes other background colors to disappear.)  Alternatively
you can keep the background color and/or box, but then have to take
special care to adjust ‘magit-branch-current’ accordingly.  By default
it looks mostly like ‘magit-branch-local’, but with a box (by default
the former is the only face that uses a box, exactly so that it sticks
out).  If the former also uses a box, then you have to make sure that it
differs in some other way from the latter.

   The most difficult faces to theme are those related to diffs,
headings, highlighting, and the region.  There are faces that fall into
all four groups - expect to spend some time getting this right.

   The ‘region’ face in the default theme, in both the light and dark
variants, as well as in many other themes, distributed with Emacs or by
third-parties, is very ugly.  It is common to use a background color
that really sticks out, which is ugly but if that were the only problem
then it would be acceptable.  Unfortunately many themes also set the
foreground color, which ensures that all text within the region is
readable.  Without doing that there might be cases where some foreground
color is too close to the region background color to still be readable.
But it also means that text within the region loses all syntax
highlighting.

   I consider the work that went into getting the ‘region’ face right to
be a good indicator for the general quality of a theme.  My
recommendation for the ‘region’ face is this: use a background color
slightly different from the background color of the ‘default’ face, and
do not set the foreground color at all.  So for a light theme you might
use a light (possibly tinted) gray as the background color of ‘default’
and a somewhat darker gray for the background of ‘region’.  That should
usually be enough to not collide with the foreground color of any other
face.  But if some other faces also set a light gray as background
color, then you should also make sure it doesn’t collide with those (in
some cases it might be acceptable though).

   Magit only uses the ‘region’ face when the region is "invalid" by its
own definition.  In a Magit buffer the region is used to either select
multiple sibling sections, so that commands which support it act on all
of these sections instead of just the current section, or to select
lines within a single hunk section.  In all other cases, the section is
considered invalid and Magit won’t act on it.  But such invalid sections
happen, either because the user has not moved point enough yet to make
it valid or because she wants to use a non-magit command to act on the
region, e.g.  ‘kill-region’.

   So using the regular ‘region’ face for invalid sections is a feature.
It tells the user that Magit won’t be able to act on it.  It’s
acceptable if that face looks a bit odd and even (but less so) if it
collides with the background colors of section headings and other things
that have a background color.

   Magit highlights the current section.  If a section has subsections,
then all of them are highlighted.  This is done using faces that have
"highlight" in their names.  For most sections,
‘magit-section-highlight’ is used for both the body and the heading.
Like the ‘region’ face, it should only set the background color to
something similar to that of ‘default’.  The highlight background color
must be different from both the ‘region’ background color and the
‘default’ background color.

   For diff related sections Magit uses various faces to highlight
different parts of the selected section(s).  Note that hunk headings,
unlike all other section headings, by default have a background color,
because it is useful to have very visible separators between hunks.
That face ‘magit-diff-hunk-heading’, should be different from both
‘magit-diff-hunk-heading-highlight’ and ‘magit-section-highlight’, as
well as from ‘magit-diff-context’ and ‘magit-diff-context-highlight’.
By default we do that by changing the foreground color.  Changing the
background color would lead to complications, and there are already
enough we cannot get around.  (Also note that it is generally a good
idea for section headings to always be bold, but only for sections that
have subsections).

   When there is a valid region selecting diff-related sibling sections,
i.e.  multiple files or hunks, then the bodies of all these sections use
the respective highlight faces, but additionally the headings instead
use one of the faces ‘magit-diff-file-heading-selection’ or
‘magit-diff-hunk-heading-selection’.  These faces have to be different
from the regular highlight variants to provide explicit visual
indication that the region is active.

   When theming diff related faces, start by setting the option
‘magit-diff-refine-hunk’ to ‘all’.  You might personally prefer to only
refine the current hunk or not use hunk refinement at all, but some of
the users of your theme want all hunks to be refined, so you have to
cater to that.

   (Also turn on ‘magit-diff-highlight-indentation’,
‘magit-diff-highlight-trailing’, and ‘magit-diff-paint-whitespace’; and
insert some whitespace errors into the code you use for testing.)

   For e.g.  "added lines" you have to adjust three faces:
‘magit-diff-added’, ‘magit-diff-added-highlight’, and
‘smerge-refined-added’.  Make sure that the latter works well with both
of the former, as well as ‘smerge-other’ and ‘diff-added’.  Then do the
same for the removed lines, context lines, lines added by us, and lines
added by them.  Also make sure the respective added, removed, and
context faces use approximately the same saturation for both the
highlighted and unhighlighted variants.  Also make sure the file and
diff headings work nicely with context lines (e.g.  make them look
different).  Line faces should set both the foreground and the
background color.  For example, for added lines use two different
greens.

   It’s best if the foreground color of both the highlighted and the
unhighlighted variants are the same, so you will need to have to find a
color that works well on the highlight and unhighlighted background, the
refine background, and the highlight context background.  When there is
an hunk internal region, then the added- and removed-lines background
color is used only within that region.  Outside the region the
highlighted context background color is used.  This makes it easier to
see what is being staged.  With an hunk internal region the hunk heading
is shown using ‘magit-diff-hunk-heading-selection’, and so are the thin
lines that are added around the lines that fall within the region.  The
background color of that has to be distinct enough from the various
other involved background colors.

   Nobody said this would be easy.  If your theme restricts itself to a
certain set of colors, then you should make an exception here.
Otherwise it would be impossible to make the diffs look good in each and
every variation.  Actually you might want to just stick to the default
definitions for these faces.  You have been warned.  Also please note
that if you do not get this right, this will in some cases look to users
like bugs in Magit - so please do it right or not at all.


File: magit.info,  Node: FAQ,  Next: Debugging Tools,  Prev: Plumbing,  Up: Top

Appendix A FAQ
**************

The next two nodes lists frequently asked questions.  For a list of
frequently *and recently* asked questions, i.e.  questions that haven’t
made it into the manual yet, see
<https://github.com/magit/magit/wiki/FAQ>.

   Please also use the *note Debugging Tools::.

* Menu:

* FAQ - How to ...?::
* FAQ - Issues and Errors::


File: magit.info,  Node: FAQ - How to ...?,  Next: FAQ - Issues and Errors,  Up: FAQ

A.1 FAQ - How to ...?
=====================

* Menu:

* How to show git's output?::
* How to install the gitman info manual?::
* How to show diffs for gpg-encrypted files?::
* How does branching and pushing work?::
* Can Magit be used as ediff-version-control-package?::
* Should I disable VC?::


File: magit.info,  Node: How to show git's output?,  Next: How to install the gitman info manual?,  Up: FAQ - How to ...?

A.1.1 How to show git’s output?
-------------------------------

To show the output of recently run git commands, press ‘$’ (or, if that
isn’t available, ‘M-x magit-process-buffer’).  This will show a buffer
containing a section per git invocation; as always press ‘TAB’ to expand
or collapse them.

   By default, git’s output is only inserted into the process buffer if
it is run for side-effects.  When the output is consumed in some way,
also inserting it into the process buffer would be too expensive.  For
debugging purposes, it’s possible to do so anyway by setting
‘magit-git-debug’ to ‘t’.


File: magit.info,  Node: How to install the gitman info manual?,  Next: How to show diffs for gpg-encrypted files?,  Prev: How to show git's output?,  Up: FAQ - How to ...?

A.1.2 How to install the gitman info manual?
--------------------------------------------

Git’s manpages can be exported as an info manual called ‘gitman’.
Magit’s own info manual links to nodes in that manual instead of the
actual manpages because Info doesn’t support linking to manpages.

   Unfortunately some distributions do not install the ‘gitman’ manual
by default and you will have to install a separate documentation package
to get it.

   Magit patches Info adding the ability to visit links to the ‘gitman’
Info manual by instead viewing the respective manpage.  If you prefer
that approach, then set the value of ‘magit-view-git-manual-method’ to
one of the supported packages ‘man’ or ‘woman’, e.g.:

     (setq magit-view-git-manual-method 'man)


File: magit.info,  Node: How to show diffs for gpg-encrypted files?,  Next: How does branching and pushing work?,  Prev: How to install the gitman info manual?,  Up: FAQ - How to ...?

A.1.3 How to show diffs for gpg-encrypted files?
------------------------------------------------

Git supports showing diffs for encrypted files, but has to be told to do
so.  Since Magit just uses Git to get the diffs, configuring Git also
affects the diffs displayed inside Magit.

     git config --global diff.gpg.textconv "gpg --no-tty --decrypt"
     echo "*.gpg filter=gpg diff=gpg" > .gitattributes


File: magit.info,  Node: How does branching and pushing work?,  Next: Can Magit be used as ediff-version-control-package?,  Prev: How to show diffs for gpg-encrypted files?,  Up: FAQ - How to ...?

A.1.4 How does branching and pushing work?
------------------------------------------

Please see *note Branching:: and
<http://emacsair.me/2016/01/18/magit-2.4>


File: magit.info,  Node: Can Magit be used as ediff-version-control-package?,  Next: Should I disable VC?,  Prev: How does branching and pushing work?,  Up: FAQ - How to ...?

A.1.5 Can Magit be used as ‘ediff-version-control-package’?
-----------------------------------------------------------

No, it cannot.  For that to work the functions ‘ediff-magit-internal’
and ‘ediff-magit-merge-internal’ would have to be implemented, and they
are not.  These two functions are only used by the three commands
‘ediff-revision’, ‘ediff-merge-revisions-with-ancestor’, and
‘ediff-merge-revisions’.

   These commands only delegate the task of populating buffers with
certain revisions to the "internal" functions.  The equally important
task of determining which revisions are to be compared/merged is not
delegated.  Instead this is done without any support whatsoever from the
version control package/system - meaning that the user has to enter the
revisions explicitly.  Instead of implementing ‘ediff-magit-internal’ we
provide ‘magit-ediff-compare’, which handles both tasks like it is 2005.

   The other commands ‘ediff-merge-revisions’ and
‘ediff-merge-revisions-with-ancestor’ are normally not what you want
when using a modern version control system like Git.  Instead of letting
the user resolve only those conflicts which Git could not resolve on its
own, they throw away all work done by Git and then expect the user to
manually merge all conflicts, including those that had already been
resolved.  That made sense back in the days when version control systems
couldn’t merge (or so I have been told), but not anymore.  Once in a
blue moon you might actually want to see all conflicts, in which case
you *can* use these commands, which then use ‘ediff-vc-merge-internal’.
So we don’t actually have to implement ‘ediff-magit-merge-internal’.
Instead we provide the more useful command ‘magit-ediff-resolve’ which
only shows yet-to-be resolved conflicts.


File: magit.info,  Node: Should I disable VC?,  Prev: Can Magit be used as ediff-version-control-package?,  Up: FAQ - How to ...?

A.1.6 Should I disable VC?
--------------------------

If you don’t use VC (the built-in version control interface) then you
might be tempted to disable it, not least because we used to recommend
that you do that.

   We no longer recommend that you disable VC.  Doing so would break
useful third-party packages (such as ‘diff-hl’), which depend on VC
being enabled.

   If you choose to disable VC anyway, then you can do so by changing
the value of ‘vc-handled-backends’.


File: magit.info,  Node: FAQ - Issues and Errors,  Prev: FAQ - How to ...?,  Up: FAQ

A.2 FAQ - Issues and Errors
===========================

* Menu:

* Magit is slow::
* I changed several thousand files at once and now Magit is unusable::
* I am having problems committing::
* I am using MS Windows and cannot push with Magit::
* I am using OS X and SOMETHING works in shell, but not in Magit: I am using OS X and SOMETHING works in shell but not in Magit.
* Expanding a file to show the diff causes it to disappear::
* Point is wrong in the COMMIT_EDITMSG buffer::
* The mode-line information isn't always up-to-date::
* A branch and tag sharing the same name breaks SOMETHING::
* My Git hooks work on the command-line but not inside Magit::
* git-commit-mode isn't used when committing from the command-line::
* Point ends up inside invisible text when jumping to a file-visiting buffer::


File: magit.info,  Node: Magit is slow,  Next: I changed several thousand files at once and now Magit is unusable,  Up: FAQ - Issues and Errors

A.2.1 Magit is slow
-------------------

See *note Performance::.


File: magit.info,  Node: I changed several thousand files at once and now Magit is unusable,  Next: I am having problems committing,  Prev: Magit is slow,  Up: FAQ - Issues and Errors

A.2.2 I changed several thousand files at once and now Magit is unusable
------------------------------------------------------------------------

Magit is *currently* not expected to work under such conditions.  It
sure would be nice if it did, and v2.5 will hopefully be a big step into
that direction.  But it might take until v3.1 to accomplish fully
satisfactory performance, because that requires some heavy refactoring.

   But for now we recommend you use the command line to complete this
one commit.  Also see *note Performance::.


File: magit.info,  Node: I am having problems committing,  Next: I am using MS Windows and cannot push with Magit,  Prev: I changed several thousand files at once and now Magit is unusable,  Up: FAQ - Issues and Errors

A.2.3 I am having problems committing
-------------------------------------

That likely means that Magit is having problems finding an appropriate
emacsclient executable.  See *note (with-editor)Configuring
With-Editor:: and *note (with-editor)Debugging::.


File: magit.info,  Node: I am using MS Windows and cannot push with Magit,  Next: I am using OS X and SOMETHING works in shell but not in Magit,  Prev: I am having problems committing,  Up: FAQ - Issues and Errors

A.2.4 I am using MS Windows and cannot push with Magit
------------------------------------------------------

It’s almost certain that Magit is only incidental to this issue.  It is
much more likely that this is a configuration issue, even if you can
push on the command line.

   Detailed setup instructions can be found at
<https://github.com/magit/magit/wiki/Pushing-with-Magit-from-Windows>.


File: magit.info,  Node: I am using OS X and SOMETHING works in shell but not in Magit,  Next: Expanding a file to show the diff causes it to disappear,  Prev: I am using MS Windows and cannot push with Magit,  Up: FAQ - Issues and Errors

A.2.5 I am using OS X and SOMETHING works in shell, but not in Magit
--------------------------------------------------------------------

This usually occurs because Emacs doesn’t have the same environment
variables as your shell.  Try installing and configuring
<https://github.com/purcell/exec-path-from-shell>.  By default it
synchronizes ‘$PATH’, which helps Magit find the same ‘git’ as the one
you are using on the shell.

   If SOMETHING is "passphrase caching with gpg-agent for commit and/or
tag signing", then you’ll also need to synchronize ‘$GPG_AGENT_INFO’.


File: magit.info,  Node: Expanding a file to show the diff causes it to disappear,  Next: Point is wrong in the COMMIT_EDITMSG buffer,  Prev: I am using OS X and SOMETHING works in shell but not in Magit,  Up: FAQ - Issues and Errors

A.2.6 Expanding a file to show the diff causes it to disappear
--------------------------------------------------------------

This is probably caused by a change of a ‘diff.*’ Git variable.  You
probably set that variable for a reason, and should therefore only undo
that setting in Magit by customizing ‘magit-git-global-arguments’.


File: magit.info,  Node: Point is wrong in the COMMIT_EDITMSG buffer,  Next: The mode-line information isn't always up-to-date,  Prev: Expanding a file to show the diff causes it to disappear,  Up: FAQ - Issues and Errors

A.2.7 Point is wrong in the ‘COMMIT_EDITMSG’ buffer
---------------------------------------------------

Neither Magit nor ‘git-commit‘ fiddle with point in the buffer used to
write commit messages, so something else must be doing it.

   You have probably globally enabled a mode which does restore point in
file-visiting buffers.  It might be a bit surprising, but when you write
a commit message, then you are actually editing a file.

   So you have to figure out which package is doing.  ‘saveplace’,
‘pointback’, and ‘session’ are likely candidates.  These snippets might
help:

     (setq session-name-disable-regexp "\\(?:\\`'\\.git/[A-Z_]+\\'\\)")

     (with-eval-after-load 'pointback
       (lambda ()
         (when (or git-commit-mode git-rebase-mode)
           (pointback-mode -1))))


File: magit.info,  Node: The mode-line information isn't always up-to-date,  Next: A branch and tag sharing the same name breaks SOMETHING,  Prev: Point is wrong in the COMMIT_EDITMSG buffer,  Up: FAQ - Issues and Errors

A.2.8 The mode-line information isn’t always up-to-date
-------------------------------------------------------

Magit is not responsible for the version control information that is
being displayed in the mode-line and looks something like ‘Git-master’.
The built-in "Version Control" package, also known as "VC", updates that
information, and can be told to do so more often:

     (setq auto-revert-check-vc-info t)

   But doing so isn’t good for performance.  For more (overly
optimistic) information see *note (emacs)VC Mode Line::.

   If you don’t really care about seeing this information in the
mode-line, but just don’t want to see _incorrect_ information, then
consider simply not displaying it in the mode-line:

     (setq-default mode-line-format
                   (delete '(vc-mode vc-mode) mode-line-format))


File: magit.info,  Node: A branch and tag sharing the same name breaks SOMETHING,  Next: My Git hooks work on the command-line but not inside Magit,  Prev: The mode-line information isn't always up-to-date,  Up: FAQ - Issues and Errors

A.2.9 A branch and tag sharing the same name breaks SOMETHING
-------------------------------------------------------------

Or more generally, ambiguous refnames break SOMETHING.

   Magit assumes that refs are named non-ambiguously across the
"refs/heads/", "refs/tags/", and "refs/remotes/" namespaces (i.e., all
the names remain unique when those prefixes are stripped).  We consider
ambiguous refnames unsupported and recommend that you use a
non-ambiguous naming scheme.  However, if you do work with a repository
that has ambiguous refnames, please report any issues you encounter so
that we can investigate whether there is a simple fix.


File: magit.info,  Node: My Git hooks work on the command-line but not inside Magit,  Next: git-commit-mode isn't used when committing from the command-line,  Prev: A branch and tag sharing the same name breaks SOMETHING,  Up: FAQ - Issues and Errors

A.2.10 My Git hooks work on the command-line but not inside Magit
-----------------------------------------------------------------

When Magit calls ‘git’ it adds a few global arguments including
‘--literal-pathspecs’ and the ‘git’ process started by Magit then passes
that setting on to other ‘git’ process it starts itself.  It does so by
setting the environment variable ‘GIT_LITERAL_PATHSPECS’, not by calling
subprocesses with the ‘--literal-pathspecs’ argument.  You can therefore
override this setting in hook scripts using ‘unset
GIT_LITERAL_PATHSPECS’.


File: magit.info,  Node: git-commit-mode isn't used when committing from the command-line,  Next: Point ends up inside invisible text when jumping to a file-visiting buffer,  Prev: My Git hooks work on the command-line but not inside Magit,  Up: FAQ - Issues and Errors

A.2.11 ‘git-commit-mode’ isn’t used when committing from the command-line
-------------------------------------------------------------------------

The reason for this is that ‘git-commit.el’ has not been loaded yet
and/or that the server has not been started yet.  These things have
always already been taken care of when you commit from Magit because in
order to do so, Magit has to be loaded and doing that involves loading
‘git-commit’ and starting the server.

   If you want to commit from the command-line, then you have to take
care of these things yourself.  Your ‘init.el’ file should contain:

     (require 'git-commit)
     (server-mode)

   Instead of ‘(require ’git-commit)‘ you may also use:

     (load "/path/to/magit-autoloads.el")

   You might want to do that because loading ‘git-commit’ causes large
parts of Magit to be loaded.

   There are also some variations of ‘(server-mode)’ that you might want
to try.  Personally I use:

     (use-package server
       :config (or (server-running-p) (server-mode)))

   Now you can use:

     $ emacs&
     $ EDITOR=emacsclient git commit

   However you cannot use:

     $ killall emacs
     $ EDITOR="emacsclient --alternate-editor emacs" git commit

   This will actually end up using ‘emacs’, not ‘emacsclient’.  If you
do this, then can still edit the commit message but ‘git-commit-mode’
won’t be used and you have to exit ‘emacs’ to finish the process.

   Tautology ahead.  If you want to be able to use ‘emacsclient’ to
connect to a running ‘emacs’ instance, even though no ‘emacs’ instance
is running, then you cannot use ‘emacsclient’ directly.

   Instead you have to create a script that does something like this:

   Try to use ‘emacsclient’ (without using ‘--alternate-editor’).  If
that succeeds, do nothing else.  Otherwise start ‘emacs &’ (and
‘init.el’ must call ‘server-start’) and try to use ‘emacsclient’ again.


File: magit.info,  Node: Point ends up inside invisible text when jumping to a file-visiting buffer,  Prev: git-commit-mode isn't used when committing from the command-line,  Up: FAQ - Issues and Errors

A.2.12 Point ends up inside invisible text when jumping to a file-visiting buffer
---------------------------------------------------------------------------------

This can happen when you type ‘RET’ on a hunk to visit the respective
file at the respective position.  One solution to this problem is to use
‘global-reveal-mode’.  It makes sure that text around point is always
visible.  If that is too drastic for your taste, then you may instead
use ‘magit-diff-visit-file-hook’ to reveal the text, possibly using
‘reveal-post-command’ or for Org buffers ‘org-reveal’.


File: magit.info,  Node: Debugging Tools,  Next: Keystroke Index,  Prev: FAQ,  Up: Top

B Debugging Tools
*****************

Magit and its dependencies provide a few debugging tools, and we
appreciate it very much if you use those tools before reporting an
issue.  Please include all relevant output when reporting an issue.

‘M-x magit-version’     (‘magit-version’)

     This command shows the currently used versions of Magit, Git, and
     Emacs in the echo area.  Non-interactively this just returns the
     Magit version.

‘M-x magit-emacs-Q-command’     (‘magit-emacs-Q-command’)

     This command shows a debugging shell command in the echo area and
     adds it to the kill ring.  Paste that command into a shell and run
     it.

     This shell command starts ‘emacs’ with only ‘magit’ and its
     dependencies loaded.  Neither your configuration nor other
     installed packages are loaded.  This makes it easier to determine
     whether some issue lays with Magit or something else.

     If you run Magit from its Git repository, then you should be able
     to use ‘make emacs-Q’ instead of the output of this command.

‘M-x magit-toggle-verbose-refresh’     (‘magit-toggle-verbose-refresh’)

     This command toggles whether Magit refreshes buffers verbosely.
     Enabling this helps figuring out which sections are bottlenecks.
     The additional output can be found in the ‘*Messages*’ buffer.

‘M-x magit-debug-git-executable’     (‘magit-debug-git-executable’)

     This command displays a buffer containing information about the
     available and used ‘git’ executable(s), and can be useful when
     investigating ‘exec-path’ issues.

     Also see *note Git Executable::.

‘M-x with-editor-debug’     (‘with-editor-debug’)

     This command displays a buffer containing information about the
     available and used ‘emacsclient’ executable(s), and can be useful
     when investigating why Magit (or rather ‘with-editor’) cannot find
     an appropriate ‘emacsclient’ executable.

     Also see *note (with-editor)Debugging::.

   Please also see the *note FAQ::.


File: magit.info,  Node: Keystroke Index,  Next: Command Index,  Prev: Debugging Tools,  Up: Top

Appendix C Keystroke Index
**************************