| Age | Commit message (Collapse) | Author |
|---|
|
See https://emacs.stackexchange.com/questions/48437.
|
|
|
|
Fixes #3700.
|
|
|
|
Closes #3676.
|
|
Before this change `git-commit-elisp-text-mode-keywords' won against
the summary element from `git-commit-font-lock-keywords-1', causing
the complete summary line to displayed like text in the body.
|
|
Both the symbol `lisp-mode-symbol-regexp' and its value appeared
in a from used to construct another regexp. That can't be right.
|
|
In the rest of Magit we call [those] things "keywords". Do so here
too. Additionally we should avoid the term "note" because it means
something else in the context of editing text using `git-commit'.
A note is an additional text that is associated to a commit (similar
to a commit message, but unlike that not actually part of the commit
object) so the same word should not be used for a certain kind of
substring of a commit message.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
When a command like "git rebase --continue" used `EDITOR' to have the
user provide a commit message and created a commit with the message it
received that way, then it goes on doing other things that may need to
lock the index.
We therefore cannot run `git-commit-post-finish-hook' after the commit
was created because otherwise there would be a race condition between
the subprocesses of "git rebase" and whatever git commands the hook
calls. Blacklist commands known to keep going after committing.
This was previously done in `magit-wip-maybe-add-commit-hook', but we
need to prevent all of `git-commit-post-finish-hook' to be inhibited.
|
|
When "emacsclient" returns, then that doesn't necessarily mean that
"git commit", which used "emacsclient" as the `EDITOR', is already
done creating the commit. We do not know the pid of "git commit",
so we have to use some other method of finding out when committing
is complete.
We do so by looping until "HEAD" points at another commit than it did
before the commit was initiated. Once that is the case we run the
hook. If "HEAD" still points at the same commit after one second,
then we give up and don't run the hook.
|
|
|
|
|
|
|
|
The merging is done using `magit-wip-commit', which does more than
just merge. It also creates the wipref if it doesn't exist yet and
that is clearly undesirable when the user hasn't enabled any of the
wip modes.
|
|
Note that there are many more commands that create commits, which do
*not* run this hook.
See #3496.
|
|
See #3496.
|
|
|
|
Fixes #3536.
|
|
Add new option `magit-wip-merge-mainline' to allow enabling
this but keep the older behavior as the default for now.
|
|
|
|
|
|
find-file-not-found-functions is run before other find-file hooks, and
so should prevent problems if any of them happen to fail due to
running with a non-existent default-directory.
|
|
... if $GIT_DIR/.dir-locals.el does not exist. The maintainer of
a project may wish to enforce some settings in buffers used to edit
commit messages, but that did not work until now when $GIT_DIR is
detached from the working tree.
|
|
This makes it possible to apply directory-local settings for buffers
used to edit commit messages based on that fake major-mode. I.e. it
is now possible to use `git-commit-mode' as a key in ".dir-locals.el".
|
|
This is intended for use as `git-commit-major-mode' for projects
that expect `symbols' to look like this. I.e. like they look in
Elisp doc-strings, including this one. Unlike in doc-strings,
"strings" also look different than the other text.
|
|
|
|
Also do so in git-commit.el's header.
|
|
|
|
|
|
|
|
This allows using "git commit" from the command-line to connect to
a running Emacs instance in which the server has been started and
in which only "magit-autoloads.el" (but not "git-commit.el" and its
dependencies) have been loaded already loaded.
$ cd /path/to/magit
$ emacs -Q ... --load lisp/magit-autoloads.el \
--eval "(add-hook 'find-file-hook 'git-commit-setup-check-buffer)" \
--funcall server-start &
$ cd /path/to/repo
$ GIT_EDITOR="emacsclient -t" git commit
"..." stands for whatever has to be done to put magit, magit-popup,
with-editor and dash on the `load-path'; in my case "-L lisp -L
../with-editor -L ../dash -L ../magit-popup".
Re #3415.
|
|
|
|
|
|
|
|
|
|
Re https://emacs.stackexchange.com/questions/40518.
|
|
By the way, in order to get the number of false-positives down to
only three, one has to teach `check-declare-verify' about `cl-defun'.
|
|
When attempting to invoke git-commit-prev-message or
git-commit-next-message in a buffer without comments, the functions
would fail with the message:
git-commit-prev-message: Search failed: "^#"
Such a buffer could be the result of a prepare-commit-msg git hook
which does not emit any comment lines.
The rest of the code was already prepared to handle this scenario, so
just fix the re-search-forward invocation to not error when the regexp
was not found, and allow the caller to handle the failure.
|
|
|
|
Fixes #3320.
|
|
Unlike what I said in the previous commit `diff-mode' does not
normally get loaded anyway. So that commit resulted in it being
loaded needlessly in the normal case.
Instead just load it when we are about to use it and declare the
used variable so that the byte-compiler knows that the variable
uses dynamic scope and has nothing to complain about.
|
|
Even without this it should get loaded, but apparently it may not,
see #3317. Even if that should turn out to be a local issue, it
would still be a good idea to make this dependency explicit.
|
|
|
|
In the past Git might have said:
Not currently on any branch.
instead of that it now says:
HEAD detached at abcdefg.
`git-commit-font-lock-keywords-2' used to have an entry for the former
but it did not have any effect because only the first submatch would
have been colorized but the regexp had no submatches.
As a result the face `git-commit-comment-detached' wasn't actually
ever used. Now it is used for the "HEAD" in the new output. Also
remove the old bogus entry and don't bother colorizing anything for
older Git versions.
|
