While we cannot (yet) claim that Magit wraps and improves upon each and every Git command, it is complete enough to allow even experienced Git users to perform almost all of their daily version control tasks directly from within Emacs. While many fine Git clients exist, only Magit and Git itself deserve to be called porcelains.
Staging and otherwise applying changes is one of the most important features in a Git porcelain and here Magit outshines anything else, including Git itself. Git’s own staging interface (git add --patch) is so cumbersome that many users only use it in exceptional cases. In Magit staging a hunk or even just part of a hunk is as trivial as staging all changes made to a file.
The most visible part of Magit’s interface is the status buffer, which displays information about the current repository. Its content is created by running several Git commands and making their output actionable. Among other things, it displays information about the current branch, lists unpulled and unpushed changes and contains sections displaying the staged and unstaged changes. That might sound noisy, but, since sections are collapsible, it’s not.
To stage or unstage a change one places the cursor on the change and then types s or u. The change can be a file or a hunk, or when the region is active (i.e. when there is a selection) several files or hunks, or even just part of a hunk. The change or changes that these commands - and many others - would act on are highlighted.
Magit also implements several other “apply variants” in addition to staging and unstaging. One can discard or reverse a change, or apply it to the working tree. Git’s own porcelain only supports this for staging and unstaging and you would have to do something like git diff ... | ??? | git apply ... to discard, revert, or apply a single hunk on the command line. In fact that’s exactly what Magit does internally (which is what lead to the term “apply variants”).
Magit isn’t just for Git experts, but it does assume some prior experience with Git as well as Emacs. That being said, many users have reported that using Magit was what finally taught them what Git it is capable off and how to use it to its fullest. Other users wished they had switched to Emacs sooner so that they would have gotten their hands on Magit earlier.
The new command `magit-do-async-shell-command' opens the file at point with `dired-do-async-shell-command'. "&" is now bound to this command. #2992
- The command `magit-bisect-run' now uses a shell to run the command entered in response to the "Enter shell command" prompt. #3001
- Discarding a renamed file failed if the original file was within a directory that no longer existed. #2998
- When inserting information about a rebase in progress into the status buffer, "exec" lines were treated as a commit, leading to an error. #3002
- The command `magit-blame' failed in blob-visiting buffers if the corresponding file no longer exists in the HEAD or the index.
- The command `magit-remote-add' asked whether to set the new remote as the `remote.pushDefault', when that variable is already set and and it was configured not to ask in that case. 4f565039 This release also contains typo fixes and documentation improvements.