2601 lines
147 KiB
Text
2601 lines
147 KiB
Text
|
This is magit.info, produced by makeinfo version 6.1 from magit.texi.
|
|||
|
|
|||
|
Copyright (C) 2015-2018 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: 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. These libraries are
|
|||
|
described in separate manuals, see *note (with-editor)Top:: and *note
|
|||
|
(magit-popup)Top::.
|
|||
|
|
|||
|
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
|
|||
|
|
|||
|
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 a sibling of that first section. When the
|
|||
|
selection is not valid then return nil. Most commands that can act
|
|||
|
on the selected sections, then instead just act on the current
|
|||
|
section, the one point is in.
|
|||
|
|
|||
|
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’. 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.
|
|||
|
|
|||
|
-- Function: magit-region-values &rest types
|
|||
|
|
|||
|
Return a list of the values of the selected sections.
|
|||
|
|
|||
|
Also see ‘magit-region-sections’ whose doc-string explains when a
|
|||
|
region is a valid section selection. If the region is not active
|
|||
|
or is not a valid section selection, then return nil. If optional
|
|||
|
TYPES is non-nil then the selection not only has to be valid; the
|
|||
|
types of all selected sections additionally have to match one of
|
|||
|
TYPES, or nil is returned.
|
|||
|
|
|||
|
|
|||
|
File: magit.info, Node: Matching Sections, Prev: Section Selection, Up: Section Plumbing
|
|||
|
|
|||
|
10.2.3 Matching Sections
|
|||
|
------------------------
|
|||
|
|
|||
|
‘M-x magit-describe-section’ (‘magit-describe-section’)
|
|||
|
|
|||
|
Show information about the section at point. This command is
|
|||
|
intended for debugging purposes.
|
|||
|
|
|||
|
-- Function: magit-section-ident
|
|||
|
|
|||
|
Return an unique identifier for SECTION. The return value has the
|
|||
|
form ‘((TYPE . VALUE)...)’.
|
|||
|
|
|||
|
-- Function: magit-get-section
|
|||
|
|
|||
|
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.
|
|||
|
|
|||
|
• ‘[TYPE...]’
|
|||
|
|
|||
|
matches if the first TYPE matches the type of the section, the
|
|||
|
second matches that of its parent, and so on.
|
|||
|
|
|||
|
• ‘[* TYPE...]’
|
|||
|
|
|||
|
matches sections that match [TYPE...] and also recursively all
|
|||
|
their child sections.
|
|||
|
|
|||
|
• ‘TYPE’
|
|||
|
|
|||
|
matches sections of TYPE regardless of the types of the parent
|
|||
|
sections.
|
|||
|
|
|||
|
Each TYPE is a symbol. Note that it is not necessary to specify
|
|||
|
all TYPEs up to the root section as printed by
|
|||
|
‘magit-describe-type’, unless of course you want to be that
|
|||
|
precise.
|
|||
|
|
|||
|
-- Function: magit-section-when condition &rest body
|
|||
|
|
|||
|
If the section at point matches CONDITION evaluate BODY.
|
|||
|
|
|||
|
If the section matches, then evaluate BODY forms sequentially with
|
|||
|
‘it’ bound to the section and return the value of the last form.
|
|||
|
If there are no BODY forms, then return the value of the section.
|
|||
|
If the section does not match or if there is no section at point
|
|||
|
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 which can change the
|
|||
|
value. For example, the ‘magit-diff-refresh-popup’ can be used to
|
|||
|
change any of the arguments used to display the diff, without
|
|||
|
having to specify again which differences should be shown.
|
|||
|
‘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::
|
|||
|
|
|||
|
|
|||
|
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 because then you get colorful output
|
|||
|
in terminals but git’s output is consumed by something else, then no
|
|||
|
colors are used.
|
|||
|
|
|||
|
If you actually use some other tool which expects that requires that
|
|||
|
you force git to output control sequences (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, 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: 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 an 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 ‘git’ 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
|
|||
|
**************************
|
|||
|
|
|||
|
|