| Age | Commit message (Collapse) | Author |
|---|
|
|
|
Previously from `git-commit-comment-branch-local',
which didn't make any sense.
|
|
|
|
Use `git-commit-font-lock-keywords-2' as the default as is done for
other such triplets. `git-commit-font-lock-keywords-3' does not yet
contain any additional fruit cake. `git-commit-font-lock-keywords-1'
is for users who want less fruit cake.
|
|
|
|
|
|
|
|
Our `git-commit-flyspell-verify' does its job as intended, but that
only keeps flyspell from actually checking words inside comments,
it does not keep it from looking at each word in comments and from
incorrectly claiming that it is checking them.
That takes time and is confusing. To avoid it, call `flyspell-region'
on the relevant part of the buffer only.
We cannot use `forward-comment' because that is syntax based, but
we cannot use syntax for comments because the comment character only
begins a comment if it is located at the beginning of a line.
|
|
Nothing to be seen here. For the time being I am the only one using
JќL bindings. Still here? Okay then, I am doing this so that I don't
accidentally switch to the previous message when I just wanted to move
to the next paragraph.
|
|
Hook functions that are run by the major-mode specified by
`git-commit-major-mode' might want to consult the state of
the minor-modes `git-commit-mode' and `with-editor-mode', but
these minor-modes are not enabled until after the major-mode.
To pretend that the minor-modes are already enabled, bind the
minor-mode variables around the call to `normal-mode'.
Closes #3184.
|
|
|
|
|
|
In `git-commit-setup' and `git-rebase-mode' do not enable
`with-editor-mode' again if it is already enabled. That mode may
already enabled if the user commits or rebases using `*-shell-command'
or from a `shell', `term`, or `eshell` buffer.
|
|
Fixes #3170.
|
|
|
|
|
|
|
|
As of Git 2.13.0 (c10388c7dc), the file for editing a branch's
description is named "EDIT_DESCRIPTION" rather than
"BRANCH_DESCRIPTION".
Fixes #3149.
|
|
Useful for inserting:
Modified-by: Jonas Bernoulli <jonas@bernoul.li>
(Though usually you would only do that if you modified
a commit originally written by someone else, obviously.)
|
|
Jonas notes: "Stefan says that the ability to set multiple variables
is only supported for backward compatibility."
https://github.com/magit/magit/pull/3101#discussion_r121172938
|
|
Until now, enabling global-git-commit-mode meant loading
git-commit.el and all of its dependencies. Exposing
git-commit-filename-regexp and git-commit-setup allows users to
defer loading the package in a more flexible way. For example, users
may wish to pair the two in an auto-mode-alist entry.
|
|
Buffers in text-mode do not define a comment syntax, which means that
auto-filling ignores a non-nil value for comment-auto-fill-only-comments
(i.e., auto-filling works on non-comments). A user would reasonably
expect a commit buffer (in the default text-mode) to behave the same,
but it does not because git-commit-mode sets up the comment syntax,
resulting in comment-auto-fill-only-comments no longer being ignored.
Explicitly set comment-auto-fill-only-comments to nil to avoid this
discrepancy.
Fixes #3068.
|
|
|
|
It was effectively obsoleted in favor of fill-column in 2.9.0 [1].
[1]: 2016-11-08 22:35:55 +0100 2087cce6c021c3f985e5c53caa74bf56ebdd30fe
git-commit: only override fill-column if not local yet
|
|
git-commit-setup always inserts a hardcoded newline after the
beginning of a new commit message and this is very annoying when
committing with --signoff because you get by default 3 empty lines
before the "Signed-off-by:" and you have to manually remove that
hardcoded line to conform to general git log style.
This happens because `git commit` also inserts a newline (only if
--signoff is used) so in that case a redundant newline is created
(thanks tarsius for figuring this out!).
So improve the check before inserting the newline to not insert if
--signoff is used, but keep old behaviour when the flag is absent.
Signed-off-by: Ioan-Adrian Ratiu <adi@adirat.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Re #2949.
|
|
This fixes a regression introduced by commit
084182e8e7dc82550543a4933c082a2a188d7faf.
According to the docstring (and the code) of 'normal-mode', when it is
called without argument, 'enable-local-variables' is ignored, so if
there are unsafe local variables, a user will be prompted about them
every time.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Third-party hooks should not be defined as options, at least not when
they have a non-nil value, because otherwise an early `add-hook' would
not add to the hook but initialize it to just the added function. But
users expect to be able to customize hooks, so we do it anyway.
Previously each `defcustom' form that defines a hook was preceded by a
form which made sure that the default functions got added to the hook
even when users added their own functions earlier. Unfortunately, and
surprisingly long undiscovered, that had the side-effect of overriding
any customization made using the Custom interface.
Now we use an approach that works in both cases, obviously.
Fixes #2902.
|
|
JќL is the name I have given to my (for now) personal key bindings,
which replace "bpnf" with "jikl" for navigation (similar to how vi
uses "hjkl", but non-modal). Maintaining such changed key bindings
across all the packages I use has proven to be challenging to say the
least. Recently I have decided to try a new approach - just patch the
packages that I use. That might seem like bad idea, and maybe it is,
but all the others didn't really scale either. (And considering that
I have written a package manager, Epkg, that is supposed to help with
exactly this sort of thing, I ought to try that approach.)
However for Magit patching is not feasible, because I work on that all
the time, and sometimes when I work on a feature branch I do have to
restart Emacs. I need my key bindings even when I am on a feature
branch and not by own personal key bindings branch.
Sometimes I add some optional functionality to Magit for the benefit
of a very small number of users, sometimes consisting of a single
user, who manages to convince me how very important a change is, even
though nobody else seems to have the same need. Well, this time that
user is me.
|
|
Some of the rearrangement is a bit strange. These changes prepare
for those that come in the next commit. Look at that if you want
to know why some binding definitions have moved to the beginnings
of their respective definition blocks.
|
|
|
|
|
|
|
|
|
|
We used to set the buffer-local value of `fill-column' in commit
message buffers to the value of option `git-commit-fill-column',
which overrides settings in ".dir-locals.el" and is surprising.
Change `git-commit-turn-on-auto-fill' to only do so if `fill-column'
does not already have a buffer-local value and if our option's value
actually is an integer. Also change the options default value to be
nil. The default value of `fill-column' is 70 and that of our option
used to be 72.
|
|
This ensures file and directory local variables are setup in the
standard way.
|
|
|
|
|
