commit | author | age
|
5cb5f7
|
1 |
This is magit.info, produced by makeinfo version 6.5 from magit.texi. |
C |
2 |
|
|
3 |
Copyright (C) 2015-2018 Jonas Bernoulli <jonas@bernoul.li> |
|
4 |
|
|
5 |
You can redistribute this document and/or modify it under the terms |
|
6 |
of the GNU General Public License as published by the Free Software |
|
7 |
Foundation, either version 3 of the License, or (at your option) |
|
8 |
any later version. |
|
9 |
|
|
10 |
This document is distributed in the hope that it will be useful, |
|
11 |
but WITHOUT ANY WARRANTY; without even the implied warranty of |
|
12 |
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU |
|
13 |
General Public License for more details. |
|
14 |
|
|
15 |
INFO-DIR-SECTION Emacs |
|
16 |
START-INFO-DIR-ENTRY |
|
17 |
* Magit: (magit). Using Git from Emacs with Magit. |
|
18 |
END-INFO-DIR-ENTRY |
|
19 |
|
|
20 |
|
|
21 |
File: magit.info, Node: Microsoft Windows Performance, Next: MacOS Performance, Up: Performance |
|
22 |
|
|
23 |
Microsoft Windows Performance |
|
24 |
............................. |
|
25 |
|
|
26 |
In order to update the status buffer, ‘git’ has to be run a few dozen |
|
27 |
times. That is problematic on Microsoft Windows, because that operating |
|
28 |
system is exceptionally slow at starting processes. Sadly this is an |
|
29 |
issue that can only be fixed by Microsoft itself, and they don’t appear |
|
30 |
to be particularly interested in doing so. |
|
31 |
|
|
32 |
Beside the subprocess issue, there are also other Windows-specific |
|
33 |
performance issues. Some of these have workarounds. The maintainers of |
|
34 |
"Git for Windows" try to improve performance on Windows. Always use the |
|
35 |
latest release in order to benefit from the latest performance tweaks. |
|
36 |
Magit too tries to work around some Windows-specific issues. |
|
37 |
|
|
38 |
According to some sources, setting the following Git variables can |
|
39 |
also help. |
|
40 |
|
|
41 |
git config --global core.preloadindex true # default since v2.1 |
|
42 |
git config --global core.fscache true # default since v2.8 |
|
43 |
git config --global gc.auto 256 |
|
44 |
|
|
45 |
You should also check whether an anti-virus program is affecting |
|
46 |
performance. |
|
47 |
|
|
48 |
|
|
49 |
File: magit.info, Node: MacOS Performance, Prev: Microsoft Windows Performance, Up: Performance |
|
50 |
|
|
51 |
MacOS Performance |
|
52 |
................. |
|
53 |
|
|
54 |
On macOS Emacs currently creates child processes using ‘fork’. It |
|
55 |
appears that this also copies GUI resources. The result is that forking |
|
56 |
takes about 30 times as long on Darwin than on Linux. And because Magit |
|
57 |
starts many ‘git’ processes even when doing simple things, that makes |
|
58 |
quite a difference. |
|
59 |
|
|
60 |
On the ‘master’ branch Emacs now uses ‘vfork’ when possible, like |
|
61 |
this was already done on Linux, and now child creation only takes about |
|
62 |
twice as long on Darwin. See (1) for more information. |
|
63 |
|
|
64 |
Nobody knows when the changes on the ‘master’ branch will be released |
|
65 |
as ‘26.1’, but it is still a long way off. You might want to get your |
|
66 |
hands on this change before then. The easiest way to get a patched |
|
67 |
Emacs is to install the ‘emacs-plus’ formula (2) using ‘homebrew’. The |
|
68 |
change has been backported, so you get it not only when using ‘--HEAD’, |
|
69 |
but also when using ‘--devel’ or when installing the latest release (by |
|
70 |
not using a version argument). |
|
71 |
|
|
72 |
Alternatively you can apply the backport (3) manually. |
|
73 |
|
|
74 |
---------- Footnotes ---------- |
|
75 |
|
|
76 |
(1) |
|
77 |
<https://lists.gnu.org/archive/html/bug-gnu-emacs/2017-04/msg00201.html> |
|
78 |
|
|
79 |
(2) <https://github.com/d12frosted/homebrew-emacs-plus> |
|
80 |
|
|
81 |
(3) |
|
82 |
<https://gist.githubusercontent.com/aaronjensen/f45894ddf431ecbff78b1bcf533d3e6b/raw/6a5cd7f57341aba673234348d8b0d2e776f86719/Emacs-25-OS-X-use-vfork.patch> |
|
83 |
|
|
84 |
|
|
85 |
File: magit.info, Node: Plumbing, Next: FAQ, Prev: Customizing, Up: Top |
|
86 |
|
|
87 |
10 Plumbing |
|
88 |
*********** |
|
89 |
|
|
90 |
The following sections describe how to use several of Magit’s core |
|
91 |
abstractions to extend Magit itself or implement a separate extension. |
|
92 |
|
|
93 |
A few of the low-level features used by Magit have been factored out |
|
94 |
into separate libraries/packages, so that they can be used by other |
|
95 |
packages, without having to depend on Magit. These libraries are |
|
96 |
described in separate manuals, see *note (with-editor)Top:: and *note |
|
97 |
(magit-popup)Top::. |
|
98 |
|
|
99 |
If you are trying to find an unused key that you can bind to a |
|
100 |
command provided by your own Magit extension, then checkout |
|
101 |
<https://github.com/magit/magit/wiki/Plugin-Dispatch-Key-Registry>. |
|
102 |
|
|
103 |
* Menu: |
|
104 |
|
|
105 |
* Calling Git:: |
|
106 |
* Section Plumbing:: |
|
107 |
* Refreshing Buffers:: |
|
108 |
* Conventions:: |
|
109 |
|
|
110 |
|
|
111 |
File: magit.info, Node: Calling Git, Next: Section Plumbing, Up: Plumbing |
|
112 |
|
|
113 |
10.1 Calling Git |
|
114 |
================ |
|
115 |
|
|
116 |
Magit provides many specialized functions for calling Git. All of these |
|
117 |
functions are defined in either ‘magit-git.el’ or ‘magit-process.el’ and |
|
118 |
have one of the prefixes ‘magit-run-’, ‘magit-call-’, ‘magit-start-’, or |
|
119 |
‘magit-git-’ (which is also used for other things). |
|
120 |
|
|
121 |
All of these functions accept an indefinite number of arguments, |
|
122 |
which are strings that specify command line arguments for Git (or in |
|
123 |
some cases an arbitrary executable). These arguments are flattened |
|
124 |
before being passed on to the executable; so instead of strings they can |
|
125 |
also be lists of strings and arguments that are ‘nil’ are silently |
|
126 |
dropped. Some of these functions also require a single mandatory |
|
127 |
argument before these command line arguments. |
|
128 |
|
|
129 |
Roughly speaking, these functions run Git either to get some value or |
|
130 |
for side-effects. The functions that return a value are useful to |
|
131 |
collect the information necessary to populate a Magit buffer, while the |
|
132 |
others are used to implement Magit commands. |
|
133 |
|
|
134 |
The functions in the value-only group always run synchronously, and |
|
135 |
they never trigger a refresh. The function in the side-effect group can |
|
136 |
be further divided into subgroups depending on whether they run Git |
|
137 |
synchronously or asynchronously, and depending on whether they trigger a |
|
138 |
refresh when the executable has finished. |
|
139 |
|
|
140 |
* Menu: |
|
141 |
|
|
142 |
* Getting a Value from Git:: |
|
143 |
* Calling Git for Effect:: |
|
144 |
|
|
145 |
|
|
146 |
File: magit.info, Node: Getting a Value from Git, Next: Calling Git for Effect, Up: Calling Git |
|
147 |
|
|
148 |
10.1.1 Getting a Value from Git |
|
149 |
------------------------------- |
|
150 |
|
|
151 |
These functions run Git in order to get a value, an exit status, or |
|
152 |
output. Of course you could also use them to run Git commands that have |
|
153 |
side-effects, but that should be avoided. |
|
154 |
|
|
155 |
-- Function: magit-git-exit-code &rest args |
|
156 |
|
|
157 |
Executes git with ARGS and returns its exit code. |
|
158 |
|
|
159 |
-- Function: magit-git-success &rest args |
|
160 |
|
|
161 |
Executes git with ARGS and returns ‘t’ if the exit code is ‘0’, |
|
162 |
‘nil’ otherwise. |
|
163 |
|
|
164 |
-- Function: magit-git-failure &rest args |
|
165 |
|
|
166 |
Executes git with ARGS and returns ‘t’ if the exit code is ‘1’, |
|
167 |
‘nil’ otherwise. |
|
168 |
|
|
169 |
-- Function: magit-git-true &rest args |
|
170 |
|
|
171 |
Executes git with ARGS and returns ‘t’ if the first line printed by |
|
172 |
git is the string "true", ‘nil’ otherwise. |
|
173 |
|
|
174 |
-- Function: magit-git-false &rest args |
|
175 |
|
|
176 |
Executes git with ARGS and returns ‘t’ if the first line printed by |
|
177 |
git is the string "false", ‘nil’ otherwise. |
|
178 |
|
|
179 |
-- Function: magit-git-insert &rest args |
|
180 |
|
|
181 |
Executes git with ARGS and inserts its output at point. |
|
182 |
|
|
183 |
-- Function: magit-git-string &rest args |
|
184 |
|
|
185 |
Executes git with ARGS and returns the first line of its output. |
|
186 |
If there is no output or if it begins with a newline character, |
|
187 |
then this returns ‘nil’. |
|
188 |
|
|
189 |
-- Function: magit-git-lines &rest args |
|
190 |
|
|
191 |
Executes git with ARGS and returns its output as a list of lines. |
|
192 |
Empty lines anywhere in the output are omitted. |
|
193 |
|
|
194 |
-- Function: magit-git-items &rest args |
|
195 |
|
|
196 |
Executes git with ARGS and returns its null-separated output as a |
|
197 |
list. Empty items anywhere in the output are omitted. |
|
198 |
|
|
199 |
If the value of option ‘magit-git-debug’ is non-nil and git exits |
|
200 |
with a non-zero exit status, then warn about that in the echo area |
|
201 |
and add a section containing git’s standard error in the current |
|
202 |
repository’s process buffer. |
|
203 |
|
|
204 |
If an error occurs when using one of the above functions, then that |
|
205 |
is usually due to a bug, i.e. using an argument which is not actually |
|
206 |
supported. Such errors are usually not reported, but when they occur we |
|
207 |
need to be able to debug them. |
|
208 |
|
|
209 |
-- User Option: magit-git-debug |
|
210 |
|
|
211 |
Whether to report errors that occur when using ‘magit-git-insert’, |
|
212 |
‘magit-git-string’, ‘magit-git-lines’, or ‘magit-git-items’. This |
|
213 |
does not actually raise an error. Instead a message is shown in |
|
214 |
the echo area, and git’s standard error is insert into a new |
|
215 |
section in the current repository’s process buffer. |
|
216 |
|
|
217 |
-- Function: magit-git-str &rest args |
|
218 |
|
|
219 |
This is a variant of ‘magit-git-string’ that ignores the option |
|
220 |
‘magit-git-debug’. It is mainly intended to be used while handling |
|
221 |
errors in functions that do respect that option. Using such a |
|
222 |
function while handing an error could cause yet another error and |
|
223 |
therefore lead to an infinite recursion. You probably won’t ever |
|
224 |
need to use this function. |
|
225 |
|
|
226 |
|
|
227 |
File: magit.info, Node: Calling Git for Effect, Prev: Getting a Value from Git, Up: Calling Git |
|
228 |
|
|
229 |
10.1.2 Calling Git for Effect |
|
230 |
----------------------------- |
|
231 |
|
|
232 |
These functions are used to run git to produce some effect. Most Magit |
|
233 |
commands that actually run git do so by using such a function. |
|
234 |
|
|
235 |
Because we do not need to consume git’s output when using these |
|
236 |
functions, their output is instead logged into a per-repository buffer, |
|
237 |
which can be shown using ‘$’ from a Magit buffer or ‘M-x magit-process’ |
|
238 |
elsewhere. |
|
239 |
|
|
240 |
These functions can have an effect in two distinct ways. Firstly, |
|
241 |
running git may change something, i.e. create or push a new commit. |
|
242 |
Secondly, that change may require that Magit buffers are refreshed to |
|
243 |
reflect the changed state of the repository. But refreshing isn’t |
|
244 |
always desirable, so only some of these functions do perform such a |
|
245 |
refresh after git has returned. |
|
246 |
|
|
247 |
Sometimes it is useful to run git asynchronously. For example, when |
|
248 |
the user has just initiated a push, then there is no reason to make her |
|
249 |
wait until that has completed. In other cases it makes sense to wait |
|
250 |
for git to complete before letting the user do something else. For |
|
251 |
example after staging a change it is useful to wait until after the |
|
252 |
refresh because that also automatically moves to the next change. |
|
253 |
|
|
254 |
-- Function: magit-call-git &rest args |
|
255 |
|
|
256 |
Calls git synchronously with ARGS. |
|
257 |
|
|
258 |
-- Function: magit-call-process program &rest args |
|
259 |
|
|
260 |
Calls PROGRAM synchronously with ARGS. |
|
261 |
|
|
262 |
-- Function: magit-run-git &rest args |
|
263 |
|
|
264 |
Calls git synchronously with ARGS and then refreshes. |
|
265 |
|
|
266 |
-- Function: magit-run-git-with-input input &rest args |
|
267 |
|
|
268 |
Calls git synchronously with ARGS and sends it INPUT on standard |
|
269 |
input. |
|
270 |
|
|
271 |
INPUT should be a buffer or the name of an existing buffer. The |
|
272 |
content of that buffer is used as the process’ standard input. |
|
273 |
After the process returns a refresh is performed. |
|
274 |
|
|
275 |
As a special case, INPUT may also be nil. In that case the content |
|
276 |
of the current buffer is used as standard input and *no* refresh is |
|
277 |
performed. |
|
278 |
|
|
279 |
This function actually runs git asynchronously. But then it waits |
|
280 |
for the process to return, so the function itself is synchronous. |
|
281 |
|
|
282 |
-- Function: magit-run-git-with-logfile file &rest args |
|
283 |
|
|
284 |
Calls git synchronously with ARGS. The process’ output is saved in |
|
285 |
FILE. This is rarely useful and so this function might be removed |
|
286 |
in the future. |
|
287 |
|
|
288 |
This function actually runs git asynchronously. But then it waits |
|
289 |
for the process to return, so the function itself is synchronous. |
|
290 |
|
|
291 |
-- Function: magit-git &rest args |
|
292 |
|
|
293 |
Calls git synchronously with ARGS for side-effects only. This |
|
294 |
function does not refresh the buffer. |
|
295 |
|
|
296 |
-- Function: magit-git-wash washer &rest args |
|
297 |
|
|
298 |
Execute Git with ARGS, inserting washed output at point. Actually |
|
299 |
first insert the raw output at point. If there is no output call |
|
300 |
‘magit-cancel-section’. Otherwise temporarily narrow the buffer to |
|
301 |
the inserted text, move to its beginning, and then call function |
|
302 |
WASHER with ARGS as its sole argument. |
|
303 |
|
|
304 |
And now for the asynchronous variants. |
|
305 |
|
|
306 |
-- Function: magit-run-git-async &rest args |
|
307 |
|
|
308 |
Start Git, prepare for refresh, and return the process object. |
|
309 |
ARGS is flattened and then used as arguments to Git. |
|
310 |
|
|
311 |
Display the command line arguments in the echo area. |
|
312 |
|
|
313 |
After Git returns some buffers are refreshed: the buffer that was |
|
314 |
current when this function was called (if it is a Magit buffer and |
|
315 |
still alive), as well as the respective Magit status buffer. |
|
316 |
Unmodified buffers visiting files that are tracked in the current |
|
317 |
repository are reverted if ‘magit-revert-buffers’ is non-nil. |
|
318 |
|
|
319 |
-- Function: magit-run-git-with-editor &rest args |
|
320 |
|
|
321 |
Export GIT_EDITOR and start Git. Also prepare for refresh and |
|
322 |
return the process object. ARGS is flattened and then used as |
|
323 |
arguments to Git. |
|
324 |
|
|
325 |
Display the command line arguments in the echo area. |
|
326 |
|
|
327 |
After Git returns some buffers are refreshed: the buffer that was |
|
328 |
current when this function was called (if it is a Magit buffer and |
|
329 |
still alive), as well as the respective Magit status buffer. |
|
330 |
|
|
331 |
-- Function: magit-start-git &rest args |
|
332 |
|
|
333 |
Start Git, prepare for refresh, and return the process object. |
|
334 |
|
|
335 |
If INPUT is non-nil, it has to be a buffer or the name of an |
|
336 |
existing buffer. The buffer content becomes the processes standard |
|
337 |
input. |
|
338 |
|
|
339 |
Option ‘magit-git-executable’ specifies the Git executable and |
|
340 |
option ‘magit-git-global-arguments’ specifies constant arguments. |
|
341 |
The remaining arguments ARGS specify arguments to Git. They are |
|
342 |
flattened before use. |
|
343 |
|
|
344 |
After Git returns, some buffers are refreshed: the buffer that was |
|
345 |
current when this function was called (if it is a Magit buffer and |
|
346 |
still alive), as well as the respective Magit status buffer. |
|
347 |
Unmodified buffers visiting files that are tracked in the current |
|
348 |
repository are reverted if ‘magit-revert-buffers’ is non-nil. |
|
349 |
|
|
350 |
-- Function: magit-start-process &rest args |
|
351 |
|
|
352 |
Start PROGRAM, prepare for refresh, and return the process object. |
|
353 |
|
|
354 |
If optional argument INPUT is non-nil, it has to be a buffer or the |
|
355 |
name of an existing buffer. The buffer content becomes the |
|
356 |
processes standard input. |
|
357 |
|
|
358 |
The process is started using ‘start-file-process’ and then setup to |
|
359 |
use the sentinel ‘magit-process-sentinel’ and the filter |
|
360 |
‘magit-process-filter’. Information required by these functions is |
|
361 |
stored in the process object. When this function returns the |
|
362 |
process has not started to run yet so it is possible to override |
|
363 |
the sentinel and filter. |
|
364 |
|
|
365 |
After the process returns, ‘magit-process-sentinel’ refreshes the |
|
366 |
buffer that was current when ‘magit-start-process’ was called (if |
|
367 |
it is a Magit buffer and still alive), as well as the respective |
|
368 |
Magit status buffer. Unmodified buffers visiting files that are |
|
369 |
tracked in the current repository are reverted if |
|
370 |
‘magit-revert-buffers’ is non-nil. |
|
371 |
|
|
372 |
-- Variable: magit-this-process |
|
373 |
|
|
374 |
The child process which is about to start. This can be used to |
|
375 |
change the filter and sentinel. |
|
376 |
|
|
377 |
-- Variable: magit-process-raise-error |
|
378 |
|
|
379 |
When this is non-nil, then ‘magit-process-sentinel’ raises an error |
|
380 |
if git exits with a non-zero exit status. For debugging purposes. |
|
381 |
|
|
382 |
|
|
383 |
File: magit.info, Node: Section Plumbing, Next: Refreshing Buffers, Prev: Calling Git, Up: Plumbing |
|
384 |
|
|
385 |
10.2 Section Plumbing |
|
386 |
===================== |
|
387 |
|
|
388 |
* Menu: |
|
389 |
|
|
390 |
* Creating Sections:: |
|
391 |
* Section Selection:: |
|
392 |
* Matching Sections:: |
|
393 |
|
|
394 |
|
|
395 |
File: magit.info, Node: Creating Sections, Next: Section Selection, Up: Section Plumbing |
|
396 |
|
|
397 |
10.2.1 Creating Sections |
|
398 |
------------------------ |
|
399 |
|
|
400 |
-- Macro: magit-insert-section &rest args |
|
401 |
|
|
402 |
Insert a section at point. |
|
403 |
|
|
404 |
TYPE is the section type, a symbol. Many commands that act on the |
|
405 |
current section behave differently depending on that type. Also if |
|
406 |
a variable ‘magit-TYPE-section-map’ exists, then use that as the |
|
407 |
text-property ‘keymap’ of all text belonging to the section (but |
|
408 |
this may be overwritten in subsections). TYPE can also have the |
|
409 |
form ‘(eval FORM)’ in which case FORM is evaluated at runtime. |
|
410 |
|
|
411 |
Optional VALUE is the value of the section, usually a string that |
|
412 |
is required when acting on the section. |
|
413 |
|
|
414 |
When optional HIDE is non-nil collapse the section body by default, |
|
415 |
i.e. when first creating the section, but not when refreshing the |
|
416 |
buffer. Otherwise, expand it by default. This can be overwritten |
|
417 |
using ‘magit-section-set-visibility-hook’. When a section is |
|
418 |
recreated during a refresh, then the visibility of predecessor is |
|
419 |
inherited and HIDE is ignored (but the hook is still honored). |
|
420 |
|
|
421 |
BODY is any number of forms that actually insert the section’s |
|
422 |
heading and body. Optional NAME, if specified, has to be a symbol, |
|
423 |
which is then bound to the struct of the section being inserted. |
|
424 |
|
|
425 |
Before BODY is evaluated the ‘start’ of the section object is set |
|
426 |
to the value of ‘point’ and after BODY was evaluated its ‘end’ is |
|
427 |
set to the new value of ‘point’; BODY is responsible for moving |
|
428 |
‘point’ forward. |
|
429 |
|
|
430 |
If it turns out inside BODY that the section is empty, then |
|
431 |
‘magit-cancel-section’ can be used to abort and remove all traces |
|
432 |
of the partially inserted section. This can happen when creating a |
|
433 |
section by washing Git’s output and Git didn’t actually output |
|
434 |
anything this time around. |
|
435 |
|
|
436 |
-- Function: magit-insert-heading &rest args |
|
437 |
|
|
438 |
Insert the heading for the section currently being inserted. |
|
439 |
|
|
440 |
This function should only be used inside ‘magit-insert-section’. |
|
441 |
|
|
442 |
When called without any arguments, then just set the ‘content’ slot |
|
443 |
of the object representing the section being inserted to a marker |
|
444 |
at ‘point’. The section should only contain a single line when |
|
445 |
this function is used like this. |
|
446 |
|
|
447 |
When called with arguments ARGS, which have to be strings, then |
|
448 |
insert those strings at point. The section should not contain any |
|
449 |
text before this happens and afterwards it should again only |
|
450 |
contain a single line. If the ‘face’ property is set anywhere |
|
451 |
inside any of these strings, then insert all of them unchanged. |
|
452 |
Otherwise use the ‘magit-section-heading’ face for all inserted |
|
453 |
text. |
|
454 |
|
|
455 |
The ‘content’ property of the section struct is the end of the |
|
456 |
heading (which lasts from ‘start’ to ‘content’) and the beginning |
|
457 |
of the body (which lasts from ‘content’ to ‘end’). If the value of |
|
458 |
‘content’ is nil, then the section has no heading and its body |
|
459 |
cannot be collapsed. If a section does have a heading then its |
|
460 |
height must be exactly one line, including a trailing newline |
|
461 |
character. This isn’t enforced; you are responsible for getting it |
|
462 |
right. The only exception is that this function does insert a |
|
463 |
newline character if necessary. |
|
464 |
|
|
465 |
-- Function: magit-cancel-section |
|
466 |
|
|
467 |
Cancel the section currently being inserted. This exits the |
|
468 |
innermost call to ‘magit-insert-section’ and removes all traces of |
|
469 |
what has already happened inside that call. |
|
470 |
|
|
471 |
-- Function: magit-define-section-jumper sym title &optional value |
|
472 |
|
|
473 |
Define an interactive function to go to section SYM. TITLE is the |
|
474 |
displayed title of the section. |
|
475 |
|
|
476 |
|
|
477 |
File: magit.info, Node: Section Selection, Next: Matching Sections, Prev: Creating Sections, Up: Section Plumbing |
|
478 |
|
|
479 |
10.2.2 Section Selection |
|
480 |
------------------------ |
|
481 |
|
|
482 |
-- Function: magit-current-section |
|
483 |
|
|
484 |
Return the section at point. |
|
485 |
|
|
486 |
-- Function: magit-region-sections &optional condition multiple |
|
487 |
|
|
488 |
Return a list of the selected sections. |
|
489 |
|
|
490 |
When the region is active and constitutes a valid section |
|
491 |
selection, then return a list of all selected sections. This is |
|
492 |
the case when the region begins in the heading of a section and |
|
493 |
ends in the heading of the same section or in that of a sibling |
|
494 |
section. If optional MULTIPLE is non-nil, then the region cannot |
|
495 |
begin and end in the same section. |
|
496 |
|
|
497 |
When the selection is not valid, then return nil. In this case, |
|
498 |
most commands that can act on the selected sections will instead |
|
499 |
act on the section at point. |
|
500 |
|
|
501 |
When the region looks like it would in any other buffer then the |
|
502 |
selection is invalid. When the selection is valid then the region |
|
503 |
uses the ‘magit-section-highlight’ face. This does not apply to |
|
504 |
diffs where things get a bit more complicated, but even here if the |
|
505 |
region looks like it usually does, then that’s not a valid |
|
506 |
selection as far as this function is concerned. |
|
507 |
|
|
508 |
If optional CONDITION is non-nil, then the selection not only has |
|
509 |
to be valid; all selected sections additionally have to match |
|
510 |
CONDITION, or nil is returned. See ‘magit-section-match’ for the |
|
511 |
forms CONDITION can take. |
|
512 |
|
|
513 |
-- Function: magit-region-values &optional condition multiple |
|
514 |
|
|
515 |
Return a list of the values of the selected sections. |
|
516 |
|
|
517 |
Return the values that themselves would be returned by |
|
518 |
‘magit-region-sections’ (which see). |
|
519 |
|
|
520 |
|
|
521 |
File: magit.info, Node: Matching Sections, Prev: Section Selection, Up: Section Plumbing |
|
522 |
|
|
523 |
10.2.3 Matching Sections |
|
524 |
------------------------ |
|
525 |
|
|
526 |
‘M-x magit-describe-section-briefly’ (‘magit-describe-section-briefly’) |
|
527 |
|
|
528 |
Show information about the section at point. This command is |
|
529 |
intended for debugging purposes. |
|
530 |
|
|
531 |
-- Function: magit-section-ident section |
|
532 |
|
|
533 |
Return an unique identifier for SECTION. The return value has the |
|
534 |
form ‘((TYPE . VALUE)...)’. |
|
535 |
|
|
536 |
-- Function: magit-get-section ident &optional root |
|
537 |
|
|
538 |
Return the section identified by IDENT. IDENT has to be a list as |
|
539 |
returned by ‘magit-section-ident’. |
|
540 |
|
|
541 |
-- Function: magit-section-match condition &optional section |
|
542 |
|
|
543 |
Return ‘t’ if SECTION matches CONDITION. SECTION defaults to the |
|
544 |
section at point. If SECTION is not specified and there also is no |
|
545 |
section at point, then return ‘nil’. |
|
546 |
|
|
547 |
CONDITION can take the following forms: |
|
548 |
• ‘(CONDITION...)’ |
|
549 |
|
|
550 |
matches if any of the CONDITIONs matches. |
|
551 |
|
|
552 |
• ‘[CLASS...]’ |
|
553 |
|
|
554 |
matches if the section’s class is the same as the first CLASS |
|
555 |
or a subclass of that; the section’s parent class matches the |
|
556 |
second CLASS; and so on. |
|
557 |
|
|
558 |
• ‘[* CLASS...]’ |
|
559 |
|
|
560 |
matches sections that match ‘[CLASS...]’ and also recursively |
|
561 |
all their child sections. |
|
562 |
|
|
563 |
• ‘CLASS’ |
|
564 |
|
|
565 |
matches if the section’s class is the same as CLASS or a |
|
566 |
subclass of that; regardless of the classes of the parent |
|
567 |
sections. |
|
568 |
|
|
569 |
Each CLASS should be a class symbol, identifying a class that |
|
570 |
derives from ‘magit-section’. For backward compatibility CLASS can |
|
571 |
also be a "type symbol". A section matches such a symbol if the |
|
572 |
value of its ‘type’ slot is ‘eq’. If a type symbol has an entry in |
|
573 |
‘magit--section-type-alist’, then a section also matches that type |
|
574 |
if its class is a subclass of the class that corresponds to the |
|
575 |
type as per that alist. |
|
576 |
|
|
577 |
Note that it is not necessary to specify the complete section |
|
578 |
lineage as printed by ‘magit-describe-section-briefly’, unless of |
|
579 |
course you want to be that precise. |
|
580 |
|
|
581 |
-- Function: magit-section-value-if condition &optional section |
|
582 |
|
|
583 |
If the section at point matches CONDITION, then return its value. |
|
584 |
|
|
585 |
If optional SECTION is non-nil then test whether that matches |
|
586 |
instead. If there is no section at point and SECTION is nil, then |
|
587 |
return nil. If the section does not match, then return nil. |
|
588 |
|
|
589 |
See ‘magit-section-match’ for the forms CONDITION can take. |
|
590 |
|
|
591 |
-- Function: magit-section-case &rest clauses |
|
592 |
|
|
593 |
Choose among clauses on the type of the section at point. |
|
594 |
|
|
595 |
Each clause looks like (CONDITION BODY...). The type of the |
|
596 |
section is compared against each CONDITION; the BODY forms of the |
|
597 |
first match are evaluated sequentially and the value of the last |
|
598 |
form is returned. Inside BODY the symbol ‘it’ is bound to the |
|
599 |
section at point. If no clause succeeds or if there is no section |
|
600 |
at point return nil. |
|
601 |
|
|
602 |
See ‘magit-section-match’ for the forms CONDITION can take. |
|
603 |
Additionally a CONDITION of t is allowed in the final clause and |
|
604 |
matches if no other CONDITION match, even if there is no section at |
|
605 |
point. |
|
606 |
|
|
607 |
-- Variable: magit-root-section |
|
608 |
|
|
609 |
The root section in the current buffer. All other sections are |
|
610 |
descendants of this section. The value of this variable is set by |
|
611 |
‘magit-insert-section’ and you should never modify it. |
|
612 |
|
|
613 |
For diff related sections a few additional tools exist. |
|
614 |
|
|
615 |
-- Function: magit-diff-type &optional section |
|
616 |
|
|
617 |
Return the diff type of SECTION. |
|
618 |
|
|
619 |
The returned type is one of the symbols ‘staged’, ‘unstaged’, |
|
620 |
‘committed’, or ‘undefined’. This type serves a similar purpose as |
|
621 |
the general type common to all sections (which is stored in the |
|
622 |
‘type’ slot of the corresponding ‘magit-section’ struct) but takes |
|
623 |
additional information into account. When the SECTION isn’t |
|
624 |
related to diffs and the buffer containing it also isn’t a |
|
625 |
diff-only buffer, then return nil. |
|
626 |
|
|
627 |
Currently the type can also be one of ‘tracked’ and ‘untracked’, |
|
628 |
but these values are not handled explicitly in every place they |
|
629 |
should be. A possible fix could be to just return nil here. |
|
630 |
|
|
631 |
The section has to be a ‘diff’ or ‘hunk’ section, or a section |
|
632 |
whose children are of type ‘diff’. If optional SECTION is nil, |
|
633 |
return the diff type for the current section. In buffers whose |
|
634 |
major mode is ‘magit-diff-mode’ SECTION is ignored and the type is |
|
635 |
determined using other means. In ‘magit-revision-mode’ buffers the |
|
636 |
type is always ‘committed’. |
|
637 |
|
|
638 |
-- Function: magit-diff-scope &optional section strict |
|
639 |
|
|
640 |
Return the diff scope of SECTION or the selected section(s). |
|
641 |
|
|
642 |
A diff’s "scope" describes what part of a diff is selected, it is a |
|
643 |
symbol, one of ‘region’, ‘hunk’, ‘hunks’, ‘file’, ‘files’, or |
|
644 |
‘list’. Do not confuse this with the diff "type", as returned by |
|
645 |
‘magit-diff-type’. |
|
646 |
|
|
647 |
If optional SECTION is non-nil, then return the scope of that, |
|
648 |
ignoring the sections selected by the region. Otherwise return the |
|
649 |
scope of the current section, or if the region is active and |
|
650 |
selects a valid group of diff related sections, the type of these |
|
651 |
sections, i.e. ‘hunks’ or ‘files’. If SECTION (or if the current |
|
652 |
section that is nil) is a ‘hunk’ section and the region starts and |
|
653 |
ends inside the body of a that section, then the type is ‘region’. |
|
654 |
|
|
655 |
If optional STRICT is non-nil then return nil if the diff type of |
|
656 |
the section at point is ‘untracked’ or the section at point is not |
|
657 |
actually a ‘diff’ but a ‘diffstat’ section. |
|
658 |
|
|
659 |
|
|
660 |
File: magit.info, Node: Refreshing Buffers, Next: Conventions, Prev: Section Plumbing, Up: Plumbing |
|
661 |
|
|
662 |
10.3 Refreshing Buffers |
|
663 |
======================= |
|
664 |
|
|
665 |
All commands that create a new Magit buffer or change what is being |
|
666 |
displayed in an existing buffer do so by calling ‘magit-mode-setup’. |
|
667 |
Among other things, that function sets the buffer local values of |
|
668 |
‘default-directory’ (to the top-level of the repository), |
|
669 |
‘magit-refresh-function’, and ‘magit-refresh-args’. |
|
670 |
|
|
671 |
Buffers are refreshed by calling the function that is the local value |
|
672 |
of ‘magit-refresh-function’ (a function named ‘magit-*-refresh-buffer’, |
|
673 |
where ‘*’ may be something like ‘diff’) with the value of |
|
674 |
‘magit-refresh-args’ as arguments. |
|
675 |
|
|
676 |
-- Macro: magit-mode-setup buffer switch-func mode refresh-func |
|
677 |
&optional refresh-args |
|
678 |
|
|
679 |
This function displays and selects BUFFER, turns on MODE, and |
|
680 |
refreshes a first time. |
|
681 |
|
|
682 |
This function displays and optionally selects BUFFER by calling |
|
683 |
‘magit-mode-display-buffer’ with BUFFER, MODE and SWITCH-FUNC as |
|
684 |
arguments. Then it sets the local value of |
|
685 |
‘magit-refresh-function’ to REFRESH-FUNC and that of |
|
686 |
‘magit-refresh-args’ to REFRESH-ARGS. Finally it creates the |
|
687 |
buffer content by calling REFRESH-FUNC with REFRESH-ARGS as |
|
688 |
arguments. |
|
689 |
|
|
690 |
All arguments are evaluated before switching to BUFFER. |
|
691 |
|
|
692 |
-- Function: magit-mode-display-buffer buffer mode &optional |
|
693 |
switch-function |
|
694 |
|
|
695 |
This function display BUFFER in some window and select it. BUFFER |
|
696 |
may be a buffer or a string, the name of a buffer. The buffer is |
|
697 |
returned. |
|
698 |
|
|
699 |
Unless BUFFER is already displayed in the selected frame, store the |
|
700 |
previous window configuration as a buffer local value, so that it |
|
701 |
can later be restored by ‘magit-mode-bury-buffer’. |
|
702 |
|
|
703 |
The buffer is displayed and selected using SWITCH-FUNCTION. If |
|
704 |
that is ‘nil’ then ‘pop-to-buffer’ is used if the current buffer’s |
|
705 |
major mode derives from ‘magit-mode’. Otherwise ‘switch-to-buffer’ |
|
706 |
is used. |
|
707 |
|
|
708 |
-- Variable: magit-refresh-function |
|
709 |
|
|
710 |
The value of this buffer-local variable is the function used to |
|
711 |
refresh the current buffer. It is called with ‘magit-refresh-args’ |
|
712 |
as arguments. |
|
713 |
|
|
714 |
-- Variable: magit-refresh-args |
|
715 |
|
|
716 |
The list of arguments used by ‘magit-refresh-function’ to refresh |
|
717 |
the current buffer. ‘magit-refresh-function’ is called with these |
|
718 |
arguments. |
|
719 |
|
|
720 |
The value is usually set using ‘magit-mode-setup’, but in some |
|
721 |
cases it’s also useful to provide commands which can change the |
|
722 |
value. For example, the ‘magit-diff-refresh-popup’ can be used to |
|
723 |
change any of the arguments used to display the diff, without |
|
724 |
having to specify again which differences should be shown. |
|
725 |
‘magit-diff-more-context’, ‘magit-diff-less-context’, and |
|
726 |
‘magit-diff-default-context’ change just the ‘-U<N>’ argument. In |
|
727 |
both case this is done by changing the value of this variable and |
|
728 |
then calling this ‘magit-refresh-function’. |
|
729 |
|
|
730 |
|
|
731 |
File: magit.info, Node: Conventions, Prev: Refreshing Buffers, Up: Plumbing |
|
732 |
|
|
733 |
10.4 Conventions |
|
734 |
================ |
|
735 |
|
|
736 |
Also see *note Completion and Confirmation::. |
|
737 |
|
|
738 |
* Menu: |
|
739 |
|
|
740 |
* Theming Faces:: |
|
741 |
|
|
742 |
|
|
743 |
File: magit.info, Node: Theming Faces, Up: Conventions |
|
744 |
|
|
745 |
10.4.1 Theming Faces |
|
746 |
-------------------- |
|
747 |
|
|
748 |
The default theme uses blue for local branches, green for remote |
|
749 |
branches, and goldenrod (brownish yellow) for tags. When creating a new |
|
750 |
theme, you should probably follow that example. If your theme already |
|
751 |
uses other colors, then stick to that. |
|
752 |
|
|
753 |
In older releases these reference faces used to have a background |
|
754 |
color and a box around them. The basic default faces no longer do so, |
|
755 |
to make Magit buffers much less noisy, and you should follow that |
|
756 |
example at least with regards to boxes. (Boxes were used in the past to |
|
757 |
work around a conflict between the highlighting overlay and text |
|
758 |
property backgrounds. That’s no longer necessary because highlighting |
|
759 |
no longer causes other background colors to disappear.) Alternatively |
|
760 |
you can keep the background color and/or box, but then have to take |
|
761 |
special care to adjust ‘magit-branch-current’ accordingly. By default |
|
762 |
it looks mostly like ‘magit-branch-local’, but with a box (by default |
|
763 |
the former is the only face that uses a box, exactly so that it sticks |
|
764 |
out). If the former also uses a box, then you have to make sure that it |
|
765 |
differs in some other way from the latter. |
|
766 |
|
|
767 |
The most difficult faces to theme are those related to diffs, |
|
768 |
headings, highlighting, and the region. There are faces that fall into |
|
769 |
all four groups - expect to spend some time getting this right. |
|
770 |
|
|
771 |
The ‘region’ face in the default theme, in both the light and dark |
|
772 |
variants, as well as in many other themes, distributed with Emacs or by |
|
773 |
third-parties, is very ugly. It is common to use a background color |
|
774 |
that really sticks out, which is ugly but if that were the only problem |
|
775 |
then it would be acceptable. Unfortunately many themes also set the |
|
776 |
foreground color, which ensures that all text within the region is |
|
777 |
readable. Without doing that there might be cases where some foreground |
|
778 |
color is too close to the region background color to still be readable. |
|
779 |
But it also means that text within the region loses all syntax |
|
780 |
highlighting. |
|
781 |
|
|
782 |
I consider the work that went into getting the ‘region’ face right to |
|
783 |
be a good indicator for the general quality of a theme. My |
|
784 |
recommendation for the ‘region’ face is this: use a background color |
|
785 |
slightly different from the background color of the ‘default’ face, and |
|
786 |
do not set the foreground color at all. So for a light theme you might |
|
787 |
use a light (possibly tinted) gray as the background color of ‘default’ |
|
788 |
and a somewhat darker gray for the background of ‘region’. That should |
|
789 |
usually be enough to not collide with the foreground color of any other |
|
790 |
face. But if some other faces also set a light gray as background |
|
791 |
color, then you should also make sure it doesn’t collide with those (in |
|
792 |
some cases it might be acceptable though). |
|
793 |
|
|
794 |
Magit only uses the ‘region’ face when the region is "invalid" by its |
|
795 |
own definition. In a Magit buffer the region is used to either select |
|
796 |
multiple sibling sections, so that commands which support it act on all |
|
797 |
of these sections instead of just the current section, or to select |
|
798 |
lines within a single hunk section. In all other cases, the section is |
|
799 |
considered invalid and Magit won’t act on it. But such invalid sections |
|
800 |
happen, either because the user has not moved point enough yet to make |
|
801 |
it valid or because she wants to use a non-magit command to act on the |
|
802 |
region, e.g. ‘kill-region’. |
|
803 |
|
|
804 |
So using the regular ‘region’ face for invalid sections is a feature. |
|
805 |
It tells the user that Magit won’t be able to act on it. It’s |
|
806 |
acceptable if that face looks a bit odd and even (but less so) if it |
|
807 |
collides with the background colors of section headings and other things |
|
808 |
that have a background color. |
|
809 |
|
|
810 |
Magit highlights the current section. If a section has subsections, |
|
811 |
then all of them are highlighted. This is done using faces that have |
|
812 |
"highlight" in their names. For most sections, |
|
813 |
‘magit-section-highlight’ is used for both the body and the heading. |
|
814 |
Like the ‘region’ face, it should only set the background color to |
|
815 |
something similar to that of ‘default’. The highlight background color |
|
816 |
must be different from both the ‘region’ background color and the |
|
817 |
‘default’ background color. |
|
818 |
|
|
819 |
For diff related sections Magit uses various faces to highlight |
|
820 |
different parts of the selected section(s). Note that hunk headings, |
|
821 |
unlike all other section headings, by default have a background color, |
|
822 |
because it is useful to have very visible separators between hunks. |
|
823 |
That face ‘magit-diff-hunk-heading’, should be different from both |
|
824 |
‘magit-diff-hunk-heading-highlight’ and ‘magit-section-highlight’, as |
|
825 |
well as from ‘magit-diff-context’ and ‘magit-diff-context-highlight’. |
|
826 |
By default we do that by changing the foreground color. Changing the |
|
827 |
background color would lead to complications, and there are already |
|
828 |
enough we cannot get around. (Also note that it is generally a good |
|
829 |
idea for section headings to always be bold, but only for sections that |
|
830 |
have subsections). |
|
831 |
|
|
832 |
When there is a valid region selecting diff-related sibling sections, |
|
833 |
i.e. multiple files or hunks, then the bodies of all these sections use |
|
834 |
the respective highlight faces, but additionally the headings instead |
|
835 |
use one of the faces ‘magit-diff-file-heading-selection’ or |
|
836 |
‘magit-diff-hunk-heading-selection’. These faces have to be different |
|
837 |
from the regular highlight variants to provide explicit visual |
|
838 |
indication that the region is active. |
|
839 |
|
|
840 |
When theming diff related faces, start by setting the option |
|
841 |
‘magit-diff-refine-hunk’ to ‘all’. You might personally prefer to only |
|
842 |
refine the current hunk or not use hunk refinement at all, but some of |
|
843 |
the users of your theme want all hunks to be refined, so you have to |
|
844 |
cater to that. |
|
845 |
|
|
846 |
(Also turn on ‘magit-diff-highlight-indentation’, |
|
847 |
‘magit-diff-highlight-trailing’, and ‘magit-diff-paint-whitespace’; and |
|
848 |
insert some whitespace errors into the code you use for testing.) |
|
849 |
|
|
850 |
For e.g. "added lines" you have to adjust three faces: |
|
851 |
‘magit-diff-added’, ‘magit-diff-added-highlight’, and |
|
852 |
‘smerge-refined-added’. Make sure that the latter works well with both |
|
853 |
of the former, as well as ‘smerge-other’ and ‘diff-added’. Then do the |
|
854 |
same for the removed lines, context lines, lines added by us, and lines |
|
855 |
added by them. Also make sure the respective added, removed, and |
|
856 |
context faces use approximately the same saturation for both the |
|
857 |
highlighted and unhighlighted variants. Also make sure the file and |
|
858 |
diff headings work nicely with context lines (e.g. make them look |
|
859 |
different). Line faces should set both the foreground and the |
|
860 |
background color. For example, for added lines use two different |
|
861 |
greens. |
|
862 |
|
|
863 |
It’s best if the foreground color of both the highlighted and the |
|
864 |
unhighlighted variants are the same, so you will need to have to find a |
|
865 |
color that works well on the highlight and unhighlighted background, the |
|
866 |
refine background, and the highlight context background. When there is |
|
867 |
an hunk internal region, then the added- and removed-lines background |
|
868 |
color is used only within that region. Outside the region the |
|
869 |
highlighted context background color is used. This makes it easier to |
|
870 |
see what is being staged. With an hunk internal region the hunk heading |
|
871 |
is shown using ‘magit-diff-hunk-heading-selection’, and so are the thin |
|
872 |
lines that are added around the lines that fall within the region. The |
|
873 |
background color of that has to be distinct enough from the various |
|
874 |
other involved background colors. |
|
875 |
|
|
876 |
Nobody said this would be easy. If your theme restricts itself to a |
|
877 |
certain set of colors, then you should make an exception here. |
|
878 |
Otherwise it would be impossible to make the diffs look good in each and |
|
879 |
every variation. Actually you might want to just stick to the default |
|
880 |
definitions for these faces. You have been warned. Also please note |
|
881 |
that if you do not get this right, this will in some cases look to users |
|
882 |
like bugs in Magit - so please do it right or not at all. |
|
883 |
|
|
884 |
|
|
885 |
File: magit.info, Node: FAQ, Next: Debugging Tools, Prev: Plumbing, Up: Top |
|
886 |
|
|
887 |
Appendix A FAQ |
|
888 |
************** |
|
889 |
|
|
890 |
The next two nodes lists frequently asked questions. For a list of |
|
891 |
frequently *and recently* asked questions, i.e. questions that haven’t |
|
892 |
made it into the manual yet, see |
|
893 |
<https://github.com/magit/magit/wiki/FAQ>. |
|
894 |
|
|
895 |
Please also use the *note Debugging Tools::. |
|
896 |
|
|
897 |
* Menu: |
|
898 |
|
|
899 |
* FAQ - How to ...?:: |
|
900 |
* FAQ - Issues and Errors:: |
|
901 |
|
|
902 |
|
|
903 |
File: magit.info, Node: FAQ - How to ...?, Next: FAQ - Issues and Errors, Up: FAQ |
|
904 |
|
|
905 |
A.1 FAQ - How to ...? |
|
906 |
===================== |
|
907 |
|
|
908 |
* Menu: |
|
909 |
|
|
910 |
* How to show git's output?:: |
|
911 |
* How to install the gitman info manual?:: |
|
912 |
* How to show diffs for gpg-encrypted files?:: |
|
913 |
* How does branching and pushing work?:: |
|
914 |
* Can Magit be used as ediff-version-control-package?:: |
|
915 |
|
|
916 |
|
|
917 |
File: magit.info, Node: How to show git's output?, Next: How to install the gitman info manual?, Up: FAQ - How to ...? |
|
918 |
|
|
919 |
A.1.1 How to show git’s output? |
|
920 |
------------------------------- |
|
921 |
|
|
922 |
To show the output of recently run git commands, press ‘$’ (or, if that |
|
923 |
isn’t available, ‘M-x magit-process-buffer’). This will show a buffer |
|
924 |
containing a section per git invocation; as always press ‘TAB’ to expand |
|
925 |
or collapse them. |
|
926 |
|
|
927 |
By default, git’s output is only inserted into the process buffer if |
|
928 |
it is run for side-effects. When the output is consumed in some way, |
|
929 |
also inserting it into the process buffer would be too expensive. For |
|
930 |
debugging purposes, it’s possible to do so anyway by setting |
|
931 |
‘magit-git-debug’ to ‘t’. |
|
932 |
|
|
933 |
|
|
934 |
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 ...? |
|
935 |
|
|
936 |
A.1.2 How to install the gitman info manual? |
|
937 |
-------------------------------------------- |
|
938 |
|
|
939 |
Git’s manpages can be exported as an info manual called ‘gitman’. |
|
940 |
Magit’s own info manual links to nodes in that manual instead of the |
|
941 |
actual manpages because Info doesn’t support linking to manpages. |
|
942 |
|
|
943 |
Unfortunately some distributions do not install the ‘gitman’ manual |
|
944 |
by default and you will have to install a separate documentation package |
|
945 |
to get it. |
|
946 |
|
|
947 |
Magit patches Info adding the ability to visit links to the ‘gitman’ |
|
948 |
Info manual by instead viewing the respective manpage. If you prefer |
|
949 |
that approach, then set the value of ‘magit-view-git-manual-method’ to |
|
950 |
one of the supported packages ‘man’ or ‘woman’, e.g.: |
|
951 |
|
|
952 |
(setq magit-view-git-manual-method 'man) |
|
953 |
|
|
954 |
|
|
955 |
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 ...? |
|
956 |
|
|
957 |
A.1.3 How to show diffs for gpg-encrypted files? |
|
958 |
------------------------------------------------ |
|
959 |
|
|
960 |
Git supports showing diffs for encrypted files, but has to be told to do |
|
961 |
so. Since Magit just uses Git to get the diffs, configuring Git also |
|
962 |
affects the diffs displayed inside Magit. |
|
963 |
|
|
964 |
git config --global diff.gpg.textconv "gpg --no-tty --decrypt" |
|
965 |
echo "*.gpg filter=gpg diff=gpg" > .gitattributes |
|
966 |
|
|
967 |
|
|
968 |
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 ...? |
|
969 |
|
|
970 |
A.1.4 How does branching and pushing work? |
|
971 |
------------------------------------------ |
|
972 |
|
|
973 |
Please see *note Branching:: and |
|
974 |
<http://emacsair.me/2016/01/17/magit-2.4> |
|
975 |
|
|
976 |
|
|
977 |
File: magit.info, Node: Can Magit be used as ediff-version-control-package?, Prev: How does branching and pushing work?, Up: FAQ - How to ...? |
|
978 |
|
|
979 |
A.1.5 Can Magit be used as ‘ediff-version-control-package’? |
|
980 |
----------------------------------------------------------- |
|
981 |
|
|
982 |
No, it cannot. For that to work the functions ‘ediff-magit-internal’ |
|
983 |
and ‘ediff-magit-merge-internal’ would have to be implemented, and they |
|
984 |
are not. These two functions are only used by the three commands |
|
985 |
‘ediff-revision’, ‘ediff-merge-revisions-with-ancestor’, and |
|
986 |
‘ediff-merge-revisions’. |
|
987 |
|
|
988 |
These commands only delegate the task of populating buffers with |
|
989 |
certain revisions to the "internal" functions. The equally important |
|
990 |
task of determining which revisions are to be compared/merged is not |
|
991 |
delegated. Instead this is done without any support whatsoever from the |
|
992 |
version control package/system - meaning that the user has to enter the |
|
993 |
revisions explicitly. Instead of implementing ‘ediff-magit-internal’ we |
|
994 |
provide ‘magit-ediff-compare’, which handles both tasks like it is 2005. |
|
995 |
|
|
996 |
The other commands ‘ediff-merge-revisions’ and |
|
997 |
‘ediff-merge-revisions-with-ancestor’ are normally not what you want |
|
998 |
when using a modern version control system like Git. Instead of letting |
|
999 |
the user resolve only those conflicts which Git could not resolve on its |
|
1000 |
own, they throw away all work done by Git and then expect the user to |
|
1001 |
manually merge all conflicts, including those that had already been |
|
1002 |
resolved. That made sense back in the days when version control systems |
|
1003 |
couldn’t merge (or so I have been told), but not anymore. Once in a |
|
1004 |
blue moon you might actually want to see all conflicts, in which case |
|
1005 |
you *can* use these commands, which then use ‘ediff-vc-merge-internal’. |
|
1006 |
So we don’t actually have to implement ‘ediff-magit-merge-internal’. |
|
1007 |
Instead we provide the more useful command ‘magit-ediff-resolve’ which |
|
1008 |
only shows yet-to-be resolved conflicts. |
|
1009 |
|
|
1010 |
|
|
1011 |
File: magit.info, Node: FAQ - Issues and Errors, Prev: FAQ - How to ...?, Up: FAQ |
|
1012 |
|
|
1013 |
A.2 FAQ - Issues and Errors |
|
1014 |
=========================== |
|
1015 |
|
|
1016 |
* Menu: |
|
1017 |
|
|
1018 |
* Magit is slow:: |
|
1019 |
* I changed several thousand files at once and now Magit is unusable:: |
|
1020 |
* I am having problems committing:: |
|
1021 |
* I am using MS Windows and cannot push with Magit:: |
|
1022 |
* 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. |
|
1023 |
* Diffs contain control sequences:: |
|
1024 |
* Expanding a file to show the diff causes it to disappear:: |
|
1025 |
* Point is wrong in the COMMIT_EDITMSG buffer:: |
|
1026 |
* The mode-line information isn't always up-to-date:: |
|
1027 |
* A branch and tag sharing the same name breaks SOMETHING:: |
|
1028 |
* My Git hooks work on the command-line but not inside Magit:: |
|
1029 |
* git-commit-mode isn't used when committing from the command-line:: |
|
1030 |
* Point ends up inside invisible text when jumping to a file-visiting buffer:: |
|
1031 |
|
|
1032 |
|
|
1033 |
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 |
|
1034 |
|
|
1035 |
A.2.1 Magit is slow |
|
1036 |
------------------- |
|
1037 |
|
|
1038 |
See *note Performance::. |
|
1039 |
|
|
1040 |
|
|
1041 |
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 |
|
1042 |
|
|
1043 |
A.2.2 I changed several thousand files at once and now Magit is unusable |
|
1044 |
------------------------------------------------------------------------ |
|
1045 |
|
|
1046 |
Magit is *currently* not expected to work under such conditions. It |
|
1047 |
sure would be nice if it did, and v2.5 will hopefully be a big step into |
|
1048 |
that direction. But it might take until v3.1 to accomplish fully |
|
1049 |
satisfactory performance, because that requires some heavy refactoring. |
|
1050 |
|
|
1051 |
But for now we recommend you use the command line to complete this |
|
1052 |
one commit. Also see *note Performance::. |
|
1053 |
|
|
1054 |
|
|
1055 |
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 |
|
1056 |
|
|
1057 |
A.2.3 I am having problems committing |
|
1058 |
------------------------------------- |
|
1059 |
|
|
1060 |
That likely means that Magit is having problems finding an appropriate |
|
1061 |
emacsclient executable. See *note (with-editor)Configuring |
|
1062 |
With-Editor:: and *note (with-editor)Debugging::. |
|
1063 |
|
|
1064 |
|
|
1065 |
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 |
|
1066 |
|
|
1067 |
A.2.4 I am using MS Windows and cannot push with Magit |
|
1068 |
------------------------------------------------------ |
|
1069 |
|
|
1070 |
It’s almost certain that Magit is only incidental to this issue. It is |
|
1071 |
much more likely that this is a configuration issue, even if you can |
|
1072 |
push on the command line. |
|
1073 |
|
|
1074 |
Detailed setup instructions can be found at |
|
1075 |
<https://github.com/magit/magit/wiki/Pushing-with-Magit-from-Windows>. |
|
1076 |
|
|
1077 |
|
|
1078 |
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 |
|
1079 |
|
|
1080 |
A.2.5 I am using OS X and SOMETHING works in shell, but not in Magit |
|
1081 |
-------------------------------------------------------------------- |
|
1082 |
|
|
1083 |
This usually occurs because Emacs doesn’t have the same environment |
|
1084 |
variables as your shell. Try installing and configuring |
|
1085 |
<https://github.com/purcell/exec-path-from-shell>. By default it |
|
1086 |
synchronizes ‘$PATH’, which helps Magit find the same ‘git’ as the one |
|
1087 |
you are using on the shell. |
|
1088 |
|
|
1089 |
If SOMETHING is "passphrase caching with gpg-agent for commit and/or |
|
1090 |
tag signing", then you’ll also need to synchronize ‘$GPG_AGENT_INFO’. |
|
1091 |
|
|
1092 |
|
|
1093 |
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 |
|
1094 |
|
|
1095 |
A.2.6 Diffs contain control sequences |
|
1096 |
------------------------------------- |
|
1097 |
|
|
1098 |
This happens when you configure Git to always color diffs and/or all of |
|
1099 |
its output. The valid values for relevant Git variables ‘color.ui’ and |
|
1100 |
‘color.diff’ are ‘false’, ‘true’ and ‘always’, and the default is |
|
1101 |
‘true’. You should leave it that way because then you get colorful |
|
1102 |
output in terminals by default but when git’s output is consumed by |
|
1103 |
something else, then no color control sequences are used. |
|
1104 |
|
|
1105 |
If you actually use some other tool that requires setting ‘color.ui’ |
|
1106 |
and/or ‘color.diff’ to ‘always’ (which is highly unlikely), then you can |
|
1107 |
override these settings just for Magit by using: |
|
1108 |
|
|
1109 |
(setq magit-git-global-arguments |
|
1110 |
(nconc magit-git-global-arguments |
|
1111 |
'("-c" "color.ui=false" |
|
1112 |
"-c" "color.diff=false"))) |
|
1113 |
|
|
1114 |
|
|
1115 |
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 |
|
1116 |
|
|
1117 |
A.2.7 Expanding a file to show the diff causes it to disappear |
|
1118 |
-------------------------------------------------------------- |
|
1119 |
|
|
1120 |
This is probably caused by a change of a ‘diff.*’ Git variable. You |
|
1121 |
probably set that variable for a reason, and should therefore only undo |
|
1122 |
that setting in Magit by customizing ‘magit-git-global-arguments’. |
|
1123 |
|
|
1124 |
|
|
1125 |
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 |
|
1126 |
|
|
1127 |
A.2.8 Point is wrong in the ‘COMMIT_EDITMSG’ buffer |
|
1128 |
--------------------------------------------------- |
|
1129 |
|
|
1130 |
Neither Magit nor ‘git-commit‘ fiddle with point in the buffer used to |
|
1131 |
write commit messages, so something else must be doing it. |
|
1132 |
|
|
1133 |
You have probably globally enabled a mode which does restore point in |
|
1134 |
file-visiting buffers. It might be a bit surprising, but when you write |
|
1135 |
a commit message, then you are actually editing a file. |
|
1136 |
|
|
1137 |
So you have to figure out which package is doing. ‘saveplace’, |
|
1138 |
‘pointback’, and ‘session’ are likely candidates. These snippets might |
|
1139 |
help: |
|
1140 |
|
|
1141 |
(setq session-name-disable-regexp "\\(?:\\`'\\.git/[A-Z_]+\\'\\)") |
|
1142 |
|
|
1143 |
(with-eval-after-load 'pointback |
|
1144 |
(lambda () |
|
1145 |
(when (or git-commit-mode git-rebase-mode) |
|
1146 |
(pointback-mode -1)))) |
|
1147 |
|
|
1148 |
|
|
1149 |
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 |
|
1150 |
|
|
1151 |
A.2.9 The mode-line information isn’t always up-to-date |
|
1152 |
------------------------------------------------------- |
|
1153 |
|
|
1154 |
Magit is not responsible for the version control information that is |
|
1155 |
being displayed in the mode-line and looks something like ‘Git-master’. |
|
1156 |
The built-in "Version Control" package, also known as "VC", updates that |
|
1157 |
information, and can be told to do so more often: |
|
1158 |
|
|
1159 |
(setq auto-revert-check-vc-info t) |
|
1160 |
|
|
1161 |
But doing so isn’t good for performance. For more (overly |
|
1162 |
optimistic) information see *note (emacs)VC Mode Line::. |
|
1163 |
|
|
1164 |
If you don’t really care about seeing that information in the |
|
1165 |
mode-line, but just don’t want to see _incorrect_ information, then |
|
1166 |
consider disabling VC when using Git: |
|
1167 |
|
|
1168 |
(setq vc-handled-backends (delq 'Git vc-handled-backends)) |
|
1169 |
|
|
1170 |
Or to disable it completely: |
|
1171 |
|
|
1172 |
(setq vc-handled-backends nil) |
|
1173 |
|
|
1174 |
|
|
1175 |
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 |
|
1176 |
|
|
1177 |
A.2.10 A branch and tag sharing the same name breaks SOMETHING |
|
1178 |
-------------------------------------------------------------- |
|
1179 |
|
|
1180 |
Or more generally, ambiguous refnames break SOMETHING. |
|
1181 |
|
|
1182 |
Magit assumes that refs are named non-ambiguously across the |
|
1183 |
"refs/heads/", "refs/tags/", and "refs/remotes/" namespaces (i.e., all |
|
1184 |
the names remain unique when those prefixes are stripped). We consider |
|
1185 |
ambiguous refnames unsupported and recommend that you use a |
|
1186 |
non-ambiguous naming scheme. However, if you do work with a repository |
|
1187 |
that has ambiguous refnames, please report any issues you encounter so |
|
1188 |
that we can investigate whether there is a simple fix. |
|
1189 |
|
|
1190 |
|
|
1191 |
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 |
|
1192 |
|
|
1193 |
A.2.11 My Git hooks work on the command-line but not inside Magit |
|
1194 |
----------------------------------------------------------------- |
|
1195 |
|
|
1196 |
When Magit calls ‘git’ it adds a few global arguments including |
|
1197 |
‘--literal-pathspecs’ and the ‘git’ process started by Magit then passes |
|
1198 |
that setting on to other ‘git’ process it starts itself. It does so by |
|
1199 |
setting the environment variable ‘GIT_LITERAL_PATHSPECS’, not by calling |
|
1200 |
subprocesses with the ‘--literal-pathspecs’. You can therefore override |
|
1201 |
this setting in hook scripts using ‘unset GIT_LITERAL_PATHSPECS’. |
|
1202 |
|
|
1203 |
|
|
1204 |
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 |
|
1205 |
|
|
1206 |
A.2.12 ‘git-commit-mode’ isn’t used when committing from the command-line |
|
1207 |
------------------------------------------------------------------------- |
|
1208 |
|
|
1209 |
The reason for this is that ‘git-commit.el’ has not been loaded yet |
|
1210 |
and/or that the server has not been started yet. These things have |
|
1211 |
always already been taken care of when you commit from Magit because in |
|
1212 |
order to do so, Magit has to be loaded and doing that involves loading |
|
1213 |
‘git-commit’ and starting the server. |
|
1214 |
|
|
1215 |
If you want to commit from the command-line, then you have to take |
|
1216 |
care of these things yourself. Your ‘init.el’ file should contain: |
|
1217 |
|
|
1218 |
(require 'git-commit) |
|
1219 |
(server-mode) |
|
1220 |
|
|
1221 |
Instead of ‘(require ’git-commit)‘ you may also use: |
|
1222 |
|
|
1223 |
(load "/path/to/magit-autoloads.el") |
|
1224 |
|
|
1225 |
You might want to do that because loading ‘git-commit’ causes large |
|
1226 |
parts of Magit to be loaded. |
|
1227 |
|
|
1228 |
There are also some variations of ‘(server-mode)’ that you might want |
|
1229 |
to try. Personally I use: |
|
1230 |
|
|
1231 |
(use-package server |
|
1232 |
:config (or (server-running-p) (server-mode))) |
|
1233 |
|
|
1234 |
Now you can use: |
|
1235 |
|
|
1236 |
$ emacs& |
|
1237 |
$ EDITOR=emacsclient git commit |
|
1238 |
|
|
1239 |
However you cannot use: |
|
1240 |
|
|
1241 |
$ killall emacs |
|
1242 |
$ EDITOR="emacsclient --alternate-editor emacs" git commit |
|
1243 |
|
|
1244 |
This will actually end up using ‘emacs’, not ‘emacsclient’. If you |
|
1245 |
do this, then can still edit the commit message but ‘git-commit-mode’ |
|
1246 |
won’t be used and you have to exit ‘emacs’ to finish the process. |
|
1247 |
|
|
1248 |
Tautology ahead. If you want to be able to use ‘emacsclient’ to |
|
1249 |
connect to a running ‘emacs’ instance, even though no ‘emacs’ instance |
|
1250 |
is running, then you cannot use ‘emacsclient’ directly. |
|
1251 |
|
|
1252 |
Instead you have to create a script that does something like this: |
|
1253 |
|
|
1254 |
Try to use ‘emacsclient’ (without using ‘--alternate-editor’). If |
|
1255 |
that succeeds, do nothing else. Otherwise start ‘emacs &’ (and |
|
1256 |
‘init.el’ must call ‘server-start’) and try to use ‘emacsclient’ again. |
|
1257 |
|
|
1258 |
|
|
1259 |
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 |
|
1260 |
|
|
1261 |
A.2.13 Point ends up inside invisible text when jumping to a file-visiting buffer |
|
1262 |
--------------------------------------------------------------------------------- |
|
1263 |
|
|
1264 |
This can happen when you type ‘RET’ on a hunk to visit the respective |
|
1265 |
file at the respective position. One solution to this problem is to use |
|
1266 |
‘global-reveal-mode’. It makes sure that text around point is always |
|
1267 |
visible. If that is too drastic for your taste, then you may instead |
|
1268 |
use ‘magit-diff-visit-file-hook’ to reveal the text, possibly using |
|
1269 |
‘reveal-post-command’ or for Org buffers ‘org-reveal’. |
|
1270 |
|
|
1271 |
|
|
1272 |
File: magit.info, Node: Debugging Tools, Next: Keystroke Index, Prev: FAQ, Up: Top |
|
1273 |
|
|
1274 |
B Debugging Tools |
|
1275 |
***************** |
|
1276 |
|
|
1277 |
Magit and its dependencies provide a few debugging tools, and we |
|
1278 |
appreciate it very much if you use those tools before reporting an |
|
1279 |
issue. Please include all relevant output when reporting an issue. |
|
1280 |
|
|
1281 |
‘M-x magit-version’ (‘magit-version’) |
|
1282 |
|
|
1283 |
This command shows the currently used versions of Magit, Git, and |
|
1284 |
Emacs in the echo area. Non-interactively this just returns the |
|
1285 |
Magit version. |
|
1286 |
|
|
1287 |
‘M-x magit-emacs-Q-command’ (‘magit-emacs-Q-command’) |
|
1288 |
|
|
1289 |
This command shows a debugging shell command in the echo area and |
|
1290 |
adds it to the kill ring. Paste that command into a shell and run |
|
1291 |
it. |
|
1292 |
|
|
1293 |
This shell command starts ‘emacs’ with only ‘magit’ and its |
|
1294 |
dependencies loaded. Neither your configuration nor other |
|
1295 |
installed packages are loaded. This makes it easier to determine |
|
1296 |
whether some issue lays with Magit or something else. |
|
1297 |
|
|
1298 |
If you run Magit from its Git repository, then you should be able |
|
1299 |
to use ‘make emacs-Q’ instead of the output of this command. |
|
1300 |
|
|
1301 |
‘M-x magit-debug-git-executable’ (‘magit-debug-git-executable’) |
|
1302 |
|
|
1303 |
This command displays a buffer containing information about the |
|
1304 |
available and used ‘git’ executable(s), and can be useful when |
|
1305 |
investigating ‘exec-path’ issues. |
|
1306 |
|
|
1307 |
Also see *note Git Executable::. |
|
1308 |
|
|
1309 |
‘M-x with-editor-debug’ (‘with-editor-debug’) |
|
1310 |
|
|
1311 |
This command displays a buffer containing information about the |
|
1312 |
available and used ‘~emacsclient’ executable(s), and can be useful |
|
1313 |
when investigating why Magit (or rather ‘with-editor’) cannot find |
|
1314 |
an appropriate ‘emacsclient’ executable. |
|
1315 |
|
|
1316 |
Also see *note (with-editor)Debugging::. |
|
1317 |
|
|
1318 |
Please also see the *note FAQ::. |
|
1319 |
|
|
1320 |
|
|
1321 |
File: magit.info, Node: Keystroke Index, Next: Command Index, Prev: Debugging Tools, Up: Top |
|
1322 |
|
|
1323 |
Appendix C Keystroke Index |
|
1324 |
************************** |
|
1325 |
|
|
1326 |
|