A.2.1 Magit is slow ¶

See Performance and I changed several thousand files at once and now Magit is unusable.

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

Magit is currently not expected to work well under such conditions. It sure would be nice if it did. Reaching satisfactory performance under such conditions will require some heavy refactoring. This is no small task but I hope to eventually find the time to make it happen.

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

A.2.3 I am having problems committing ¶

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

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.

A.2.5 I am using macOS 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.

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

This is probably caused by a customization 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.

A.2.7 Point is wrong in the COMMIT_EDITMSG buffer ¶

Neither Magit nor git-commit.el 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 restores 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 it. 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))))

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

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

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

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

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

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

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

Or more generally, ambiguous refnames break SOMETHING.

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

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

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

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

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

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

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

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

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

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

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

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

Now you can use:

$ emacs&
$ EDITOR=emacsclient git commit

However you cannot use:

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

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

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

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

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

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

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

A.2.13 I am no longer able to save popup defaults ¶

Magit used to use Magit-Popup to implement the transient popup menus. Now it used Transient instead, which is Magit-Popup’s successor.

In the older Magit-Popup menus, it was possible to save user settings (e.g., setting the gpg signing key for commits) by using C-c C-c in the popup buffer. This would dismiss the popup, but save the settings as the defaults for future popups.

When switching to Transient menus, this functionality is now available via C-x C-s instead; the C-x prefix has other options as well when using Transient, which will be displayed when it is typed. See https://magit.vc/manual/transient/Saving-Values.html#Saving-Values for more details.