82fdd9a511
Motivation While disabling Evil in holy-mode makes its implementation shorter and sounds elegant on the paper, in practice it puts a big burden on the configuration parts which need to know if Evil is enable or not. This is a bad separation of concerns and the bunch of fixes that we were forced to do in the past weeks shows this issue. Those fixes were about removing the knowledge of the activation of Evil by implementing new dispatching functions to be used by layers, this is cumbersome and makes Spacemacs layer configuration more subtle which is not good. There was additional bad consequences of the removal of Evil state like the impossibility to use Evil lisp state or iedit states, or we would have been forced to implement a temporary activation of Evil which is awkward. Instead I reintroduce Evil as the central piece of Spacemacs design thus Evil is now re-enabled in holy-mode. It provides the abstraction we need to isolate editing styles and be able to grow the Spacemacs configuration coverage sanely. Layers don't need to check whether the holy mode is active or not and they don't need to know if Evil is available (it is always available). We also don't need to write additional dispatching functions, this is the job of Evil, and I think it provides everything for this. Ideally configuration layer should be implemented with only Evil in mind and the holy-mode (and hybrid-mode) should magically make it work for Emacs style users, for instance we can freely use `evil-insert-state` anywhere in the code without any guard. Evil is now even more part of Spacemacs, we can really say that Spacemacs is Emacs+Evil which is now an indivisible pair. Spacemacs needed this stable API to continue on the right track. While these changes should be rather transparent to the user, I'm sorry for this experimental period, I failed to see all the implications of such a change, I was just excited about the possibility to make Evil optional. The reality is that Spacemacs has to embrace it and keep its strong position on being Emacs+Evil at the core. Implementation - insert, motion and normal states are forced to emacs state using an advice on `evil-insert-state`, `evil-motion-state` and `evil-normal-state` respectively. These functions can be used freely in the layer configuration. - A new general hook `spacemacs-editing-style-hook` allow to hook any code that need to be configured based on the editing style. Functions hooked to this hook takes the current style as parameter, this basically generalize the hook used to setup hjkl navigation bindings. - ESC has been removed from the emacs state map. - Revert unneeded changes - Revert "evil: enter insert-state only from normal-state" commit |
||
---|---|---|
.. | ||
img | ||
config.el | ||
packages.el | ||
README.org |
Git contribution layer for Spacemacs
Description
This layers adds extensive support for git.
Features:
- git repository management the indispensable magit package
- git-flow add-on for magit.
- quick in buffer history browsing with git-timemachine.
- quick in buffer last commit message per line with git-messenger
- colorize buffer line by age of commit with smeargle
- gitignore generator with helm-gitignore
- org integration with magit via orgit
New to Magit? Checkout the official intro.
Install
Layer
To use this configuration layer, add it to your ~/.spacemacs
. You will need to
add git
to the existing dotspacemacs-configuration-layers
list in this
file.
Magit status fullscreen
To display the magit status
buffer in fullscreen set the variable
git-magit-status-fullscreen
to t
in your dotspacemacs/user-init
function.
(defun dotspacemacs/user-init ()
(setq-default git-magit-status-fullscreen t)
)
Magit auto-complete
Magit auto-complete feature is enabled. For this feature to work best you
have to setup your Git repository directory in your dotspacemacs/user-config
function, this is the folder where you keep all your git-controlled projects
(the path should end up with a /
to respect Emacs conventions):
(setq magit-repository-directories '("~/repos/"))
For more information, see Magit-User-Manual#Status-buffer
Magit SVN plugin
For convenience the magit SVN plugin can be activated directly in the Git
layer by setting the variable git-enable-magit-svn-plugin
to t
.
(defun dotspacemacs/user-init ()
(setq-default git-enable-magit-svn-plugin t)
)
Global git commit mode
Spacemacs can be used as the $EDITOR
(or $GIT_EDITOR
) for editing git
commits messages. To enable this you have to add the following line to your
dotspacemacs/user-config
:
(global-git-commit-mode t)
Git
Of course if your OS does not ship with git (!) you'll have to install it on your machine. You can download it from the download page.
Git-Flow
Git-flow is a standardized branching pattern for git repositories with the aim of making things more manageable. While there are tools to assist with making this easier, these do nothing you couldn't do manually.
Support requires installation of the git-flow extensions. Please reference their installation page for assistance.
Org integration
See the commentary section of the package here.
Working with Git
Git commands (start with g
):
Key Binding | Description |
---|---|
SPC g A |
show cherry-pick prompt |
SPC g b |
open a magit blame |
SPC g B |
quit magit blame |
SPC g c |
commit changes |
SPC g C |
checkout branches |
SPC g d |
show diff prompt |
SPC g D |
show diff against current head |
SPC g e |
show ediff comparison |
SPC g E |
show ediff against current head |
SPC g f |
show fetch prompt |
SPC g F |
show pull prompt |
SPC g H c |
clear highlights |
SPC g H h |
highlight regions by age of commits |
SPC g H t |
highlight regions by last updated time |
SPC g i |
git init a given directory |
SPC g I |
open helm-gitignore |
SPC g l |
open a magit log |
SPC g L |
display the log for a file |
SPC g r |
show rebase prompt |
SPC g P |
show push prompt |
SPC g s |
open a magit status window |
SPC g S |
stage current file |
SPC g m |
display the last commit message of the current line |
SPC g t |
launch the git time machine |
SPC g U |
unstage current file |
- Highlight by age of commit or last update time is provided by smeargle.
- Git time machine is provided by git-timemachine.
- Git last commit message per line is provided by git-messenger.
Magit
Spacemacs uses magit to manage Git repositories.
To open a status buffer
, type in a buffer of a Git repository: SPC g s
Spacemacs uses evil-magit for key bindings in magit buffers (unless your editing style is set to emacs, in which case you get the default magit bindings), which are the standard magit key bindings with some minimal changes to make them comfortable for evil users.
Here are the often used bindings inside a status buffer
:
Key Binding | Description |
---|---|
/ |
evil-search |
$ |
open command output buffer |
c c |
open a commit message buffer |
b b |
checkout a branch |
b c |
create a branch |
f f |
fetch changes |
F (r) u |
pull tracked branch and rebase |
gr |
refresh |
j |
goto next magit section |
C-j |
next visual line |
k |
goto previous magit section |
C-k |
previous visual line |
l l |
open log buffer |
n |
next search occurrence |
N |
previous search occurrence |
o |
revert item at point |
P u |
push to tracked branch |
P m |
push to matching branch (e.g., upstream/develop to origin/develop) |
q |
quit |
s |
on a file or hunk in a diff: stage the file or hunk |
x |
discard changes |
+ |
on a hunk: increase hunk size |
- |
on a hunk: decrease hunk size |
S |
stage all |
TAB |
on a file: expand/collapse diff |
u |
on a staged file: unstage |
U |
unstage all staged files |
v or V |
select multiple lines |
z z |
stash changes |
Staging lines
Magit allows you to stage specific lines by selecting them in a diff and hitting
s
to stage. Due to inconsistencies between Vim and Emacs editing styles, if
you enter visual line state with V
, you will stage one more line than
intended. To work around this, you can use v
instead (since Magit only stages
whole lines, in any case).
Commit message editing buffer
In a commit message buffer press ,c
(if dotspacemacs-major-mode-leader-key
is ,
)
or C-c C-c
to commit the changes with the entered message. Pressing ,a
or C-c C-k
will discard the commit message.
Key Binding | Description |
---|---|
h |
go left |
j |
go down |
k |
go up |
l |
go right |
Interactive rebase buffer
Key Binding | Description |
---|---|
c or p |
pick |
e |
edit |
f |
fixup |
j |
go down |
gj |
move line down |
k |
go up |
gk |
move line up |
d or x |
kill line |
r |
reword |
s |
squash |
u |
undo |
y |
insert |
! |
execute |
Quick guide for recurring use cases in Magit
-
Amend a commit:
l l
to openlog buffer
c a
on the commit you want to amend,c
orC-c C-c
to submit the changes
-
Squash last commit:
l l
to openlog buffer
r e
on the second to last commit, it opens therebase buffer
j
to put point on last commits
to squash it,c
orC-c C-c
to continue to thecommit message buffer
,c
orC-c C-c
again when you have finished to edit the commit message
-
Force push a squashed commit:
- in the
status buffer
you should see the new commit unpushed and the old commit unpulled P -f P
for force a push (beware usually it is not recommended to rewrite the history of a public repository, but if you are sure that you are the only one to work on a repository it is ok - i.e. in your fork).
- in the
-
Add upstream remote (the parent repository you have forked):
M
to open theremote popup
a
to add a remote, type the name (i.e.upstream
) and the URL
-
Pull changes from upstream (the parent repository you have forked) and push:
F -r C-u F
and chooseupstream
or the name you gave to itP P
to push the commit toorigin
Git-Flow
magit-gitflow provides git-flow commands in its own magit menu.
Key Binding | Description |
---|---|
% |
open magit-gitflow menu |
Git time machine
git-timemachine allows to quickly browse the commits of the current buffer.
Key Binding | Description |
---|---|
SPC g t |
start git timemachine and initiate transient-state |
c |
show current commit |
n |
show next commit |
N |
show previous commit |
p |
show previous commit |
q |
leave transient-state and git timemachine |
Y |
copy current commit hash |