| Age | Commit message (Collapse) | Author |
|
No longer use `magit-worktree-read-directory-name-function', which
is still used by commands that create new worktrees. A fancy user
function suitable for worktree creation is likely contra-productive
when moving an existing worktree.
|
|
The same branch cannot be checked out in multiple worktrees.
|
|
|
|
|
|
|
|
|
|
- Never use REVISION.
- For arguments of commands use COMMIT.
- For arguments of other functions use REV.
|
|
|
|
Use this face for branch names in "# Branch" and "merge" lines, but
do not use it in "label" lines. The former two mark the points were
a branch is created and merged, while the latter is an implementation,
needed for technical reasons.
Relocate the keyword for "# Branch", so that it is placed among the
action line keywords instead of after the keywords for the comments
that optionally follow the action lines.
|
|
In "merge" lines the description was always prefixed with "# ".
Since Git v2.50.0 that is also done for other action lines.
To support older releases, "# " has to be optional for these other
action lines. While that isn't necessary, make it optional for
"merge" lines as well.
Note that Git always uses "#"; `core.commentChar' does not control
the character used here.
Never-the-less start using `font-lock-comment-face' for this inline
"#"; frankly it is unnecessary noise that is best diminished.
|
|
|
|
Tweak the merge regexp in `git-rebase-line-regexps' so that it can be
used for merge lines with and without a description.
|
|
|
|
|
|
|
|
|
|
|
|
Use the same code to generate a list of untracked fils, when
`magit-discard' is invoked on the "Untracked files" section as
was used to populate the list of files displayed in that section.
We should do that even if it weren't for the following issue, but
that is how we noticed something had to be done.
Contrary to what the documentation claims, "git ls-files --other
--directory --exclude-standard" does not honor ".gitignore" from
sub-directories.
Closes #5405.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
`magit-section-goto-successor' no longer runs
`magit-section-movement-hook', so we don't have to suppress it in
`magit--refresh-buffer-set-positions'. Since that hook was why we
wanted to handle the selected window last, when it displayed the
buffer being refreshed, we can also stop changing the order of the
windows returned by ``magit--refresh-buffer-get-positions'.
|
|
|
|
|
|
|
|
|
|
|
|
This variable is also reset in `magit-section-pre-command-hook' but that
only affects the current buffer. We also have to reset this cache when
refreshing a buffer, otherwise it would continue to track sections from
the previous generation, which no longer exist.
For example, if point is on an unstage hunk in the status and the user
invokes a commit command, then the commit message buffer is current when
the commit is finalized. In that case `magit-section-update-paint' was
called for two section in the status buffer; the previous generation
hunk (which ended up being a noop) and the actually focused hunk (which
was not included in the value returned by `magit-focused-sections',
because that cache had not been invalidated yet, and thus got painted
as unfocused).
|
|
There appears to be a change in Emacs 31 compared to 28.2, which makes
this unnecessary, but on the older release we otherwise get an error
about the `##' forms being invalid functions. Even for newer releases
it's better to use code instead of data.
Closes #5399.
|
|
|
|
|
|
Inform the user that the process buffer contains the full error
(and other output), regardless of whether `message' or `signal'
is used to show a short error message in the echo area.
Closes #5396.
|
|
|
|
|
|
|
|
We don't know since when "--grep" and "--graph" are no longer
mutually exclusive, but it is since before Git v2.25.0, which
is the minimal version required by Magit.
Closes #5391.
|
|
Closes #5394.
|
|
When we navigate to a collapsed hunk, whose body is secretly already
highlighted and expand it, we can (and already do) avoid painting it
again. However, we failed to register it as painted again, which is
necessary to cause it to be unhighlighted once we move away from it,
regardless of how far back the painting as highlighted occurred.
We do not just leave the section registered as painted, after collapsing
it and then moving away, because `magit-section-update-highlight' would
then have to consider its state after every command.
Closes #5393.
Suggested-by: Eliza Velasquez
|
|
Since v4.3.7 the overlays used for section highlighting and section
selection conflicted, if both of these faces relied on the same face
property (likely the foreground color). The usual way to theme these
faces is to use the background for highlighting and the foreground for
the selection.
Closes #5389.
|
|
Closes #5388.
|
|
This makes it possible to use Magit's bookmark support in Forge.
|
|
|
|
Applying the region used to fail, even if the changes withing would
apply but some other part of the hunk, outside the region, conflicts
with the target.
|