|
|
- This is magit.info, produced by makeinfo version 6.5 from magit.texi.
-
- Copyright (C) 2015-2019 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 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))))
-
- 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 the 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. Setting
- ‘magit-refresh-verbose’ and then inspecting the output in the
- ‘*Messages*’ buffer, should help doing so.
-
- 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::.
-
- * 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’.
-
- 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.
-
- The Built-In VC Package
- .......................
-
- Emacs comes with a version control interface called "VC", see *note
- (emacs)Version Control::. It is enabled be default, and if you don’t
- use it in addition to Magit, then you should disable it to keep it from
- performing unnecessary work:
-
- (setq vc-handled-backends nil)
-
- You can also disable its use for Git but keep using it when using
- another version control system:
-
- (setq vc-handled-backends (delq 'Git vc-handled-backends))
-
- 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
- .................
-
- On macOS Emacs currently creates child processes using ‘fork’. It
- appears that this also copies GUI resources. The result is that forking
- takes about 30 times as long on Darwin than on Linux. And because Magit
- starts many ‘git’ processes even when doing simple things, that makes
- quite a difference.
-
- On the ‘master’ branch Emacs now uses ‘vfork’ when possible, like
- this was already done on Linux, and now child creation only takes about
- twice as long on Darwin. See (1) for more information.
-
- Nobody knows when the changes on the ‘master’ branch will be released
- as ‘26.1’, but it is still a long way off. You might want to get your
- hands on this change before then. The easiest way to get a patched
- Emacs is to install the ‘emacs-plus’ formula (2) using ‘homebrew’. The
- change has been backported, so you get it not only when using ‘--HEAD’,
- but also when using ‘--devel’ or when installing the latest release (by
- not using a version argument).
-
- Alternatively you can apply the backport (3) manually.
-
- ---------- Footnotes ----------
-
- (1)
- <https://lists.gnu.org/archive/html/bug-gnu-emacs/2017-04/msg00201.html>
-
- (2) <https://github.com/d12frosted/homebrew-emacs-plus>
-
- (3)
- <https://gist.githubusercontent.com/aaronjensen/f45894ddf431ecbff78b1bcf533d3e6b/raw/6a5cd7f57341aba673234348d8b0d2e776f86719/Emacs-25-OS-X-use-vfork.patch>
-
- 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’ 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’ 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?::
-
- 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/17/magit-2.4>
-
- File: magit.info, Node: Can Magit be used as ediff-version-control-package?, 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: 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.
- * Diffs contain control sequences::
- * 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: Diffs contain control sequences, 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: Diffs contain control sequences, Next: Expanding a file to show the diff causes it to disappear, Prev: I am using OS X and SOMETHING works in shell but not in Magit, Up: FAQ - Issues and Errors
-
- A.2.6 Diffs contain control sequences
- -------------------------------------
-
- This happens when you configure Git to always color diffs and/or all of
- its output. The valid values for relevant Git variables ‘color.ui’ and
- ‘color.diff’ are ‘false’, ‘true’ and ‘always’, and the default is
- ‘true’. You should leave it that way because then you get colorful
- output in terminals by default but when git’s output is consumed by
- something else, then no color control sequences are used.
-
- If you actually use some other tool that requires setting ‘color.ui’
- and/or ‘color.diff’ to ‘always’ (which is highly unlikely), then you can
- override these settings just for Magit by using:
-
- (setq magit-git-global-arguments
- (nconc magit-git-global-arguments
- '("-c" "color.ui=false"
- "-c" "color.diff=false")))
-
- 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: Diffs contain control sequences, Up: FAQ - Issues and Errors
-
- A.2.7 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.8 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.9 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 that information in the
- mode-line, but just don’t want to see _incorrect_ information, then
- consider disabling VC when using Git:
-
- (setq vc-handled-backends (delq 'Git vc-handled-backends))
-
- Or to disable it completely:
-
- (setq vc-handled-backends nil)
-
- 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.10 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.11 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’. 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.12 ‘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.13 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-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
- **************************
-
|