| Age | Commit message (Collapse) | Author |
|---|
|
|
|
magit-current-blame-chunk passes the result of
magit-file-relative-name to git-blame. For a Dired buffer, this value
is default-directory, and passing a directory to git-blame will lead
to an error. This error can show up when various commands unrelated
to magit-blame are called from a Dired buffer because
magit-current-blame-chunk is called by magit-commit-at-point and
magit-branch-or-commit-at-point.
Don't try to blame the return value of magit-file-relative-name when
in a Dired buffer, letting the "no file" case be handled according
NOERROR.
Fixes #4560.
|
|
|
|
|
|
The idea is to make it easier to see in which repositories
a feature branch is checked out.
|
|
Go back to include the height of the decent part in the calculation.
The actual problem was that on hidef monitors the `:scale' is set to
a number greater than 1 (rendering our careful calculation moot) and
our attempt to override that failed.
|
|
Fixes a regression introduced in [1: bac25e73c].
1: 2021-08-29 bac25e73c50fda8ed319cebb69f20e56f8bc7376
Avoid needless selection re-highlighting
|
|
If the git directory is separate from the main worktree,
then "git worktree" returns the git directory instead of
the worktree, which isn't what it is supposed to do and
now what we want.
|
|
- Actually compare the remote parts as intended.
- Remove a redundant condition.
Closes #4292.
|
|
|
|
|
|
|
|
The modified readers prefer the branch at point (if any) over the
commit at point. In some cases the user might prefer the commit in
some cases so we now offer that as the first "next history element".
Closes #4291.
|
|
The old attempt in [1: 1301db2c2] did not work because region
highlighting is updated more often than section highlighting
(on redisplay, not just on post-command-hook) and the former
always reset the state that could allow for the latter to be
avoided.
Closes #3976.
1: 2015-04-29 1301db2c2e6e21beac50fa215d543c09bb8516c5
avoid re-highlighting when moving within the same section
|
|
magit-wip-update-wipref switched the reflog message from "restart
autosaving ..." to "start autosaving ..." in 40c06c51 (wipref: Support
automatic merging of real branch into wip ref, 2018-08-02).
magit-wip-log-get-tips searches for this message in order to find
previous tips of the wip refs, but its regular expression wasn't
updated with that commit.
Teach magit-wip-log-get-tips to look for the new reflog message in
addition to the old one. With Git's default gc settings, it's pretty
unlikely to encounter the old message at this point, but a user may
have set gc.reflogExpire to "never".
|
|
Closes #4392.
|
|
Closes #4094.
|
|
This function does not reliably return the number of lines between
two positions. It returns either that, or that plus one; which is
of course completely bonkers.
Closes #4148.
|
|
|
|
Closes #4259.
|
|
Closes #4387.
|
|
Closes #4379.
|
|
Like some "git stash save" variants, `magit-stash-both' calls "git
reset --hard", which among other things discards merge state. This
is intentional but likely surprising so ask users if they really
want that.
Closes #4345.
|
|
Closes #4206.
|
|
No longer automatically add `--full-history' when showing log for a
single file that isn't being tracked anymore.
- In many cases this argument isn't needed to ensure that there aren't
zero commits shown for a removed file.
- This argument can be relatively expensive.
This reverts [1: 1cda70250], closes #4381.
1: 2017-10-26 1cda7025014c6e2efc859379b3d7ac8bd9a4109a
magit-log-refresh-buffer: add --full-history for single removed file
|
|
|
|
|
|
|
|
|
|
|
|
Closes https://github.com/magit/forge/issues/375.
|
|
|
|
|
|
|
|
|
|
Among other things we use crm to read revision ranges such as
"A..B" and "C...D". As far as crm is concerned ".." and "..." are
interchangeable separators but to Git they mean different things.
We cannot use `completing-read-multiple' when reading ranges because
it returns a list of the read values, stripping the separators.
`magit-completing-read-multiple' was added in [1: 388a9a254] to avoid
some (additional upcoming) duplication between our two functions that
read ranges.
Giving it that name was a mistake because its function signature
is not compatible with that of `completing-read-multiple'. In
[2: cb4d59190] `magit-completing-read-multiple*' was added to fix
that, but we did not port existing callers immediately because of
the involved risk.
Meanwhile we added more kludges to `magit-completing-read-multiple'
and `magit-completing-read-multiple*', addressing additional defects
and undesirable features of various completion frameworks.
Now the time has come to deprecate `magit-completing-read-multiple'
in favor of `magit-completing-read-multiple*'. We should stop using
the former name for now, because of the differences in the function
signatures. Eventually we would like to use the former name again,
but if we abruptly changing the signature of an existing function,
that would risk breaking third-party packages. The use of an
intermediate function name minimizes the risk to third-parties.
The previous approach was to copied `completing-read-multiple' and
to modified the copy to our needs, but we then failed to incorporate
upstream changes into our copies, so now we use a wrapper instead.
Another reason to use a wrapper is that then we don't bypass any
advice that may have been added to the original. For example the
`vertico' completion framework advices `completing-read-multiple'
but that advise obviously did not affect our copies.
1: 388a9a254f6ee985e67926d44a2d9ebad79af897
completion: move common crm setup to a function
2: cb4d591900187b77e54ec00cac5f25b644153b5b
magit-completing-read-multiple*: New function
Because this commit shuffles things around quite a bit, making history
inspection harder, I have added a code comment for each issue that our
wrapper addresses.
Co-authored-by: Miha Rihtaršič <miha@kamnitnik.top>
- Avoid changing the return value of split-string as doing that
would break selectrum's crm function.
- Cosmetics.
|
|
Since `magit-log-select-quit-function' is a buffer-local variable,
killing the buffer then calling the function means that nothing is
ever called. The quit function should be temporarily bound so it
isn't lost.
|
|
Closes #4418.
|
|
As of 56354898 (Run "git bisect" asynchronously, 2019-04-20),
magit-git-bisect runs `git bisect' calls asynchronously. While
beneficial in most spots, this switch creates a race if
magit-bisect-run is called when a bisect hasn't been started.
In that case, magit-bisect-run calls magit-bisect-start (which calls
the asynchronous magit-git-bisect underneath) and then immediately
follows with a `git bisect run' call via magit-git-bisect. This
second call depends on the first asynchronous call completing, so it
leads to a "Not bisecting" user error. That's quickly buried when the
magit-bisect-start call finishes, and the end result looks like the
user just called magit-bisect-start.
Before 56354898, magit-git-bisect used the now removed
magit-run-git-with-logfile. Inline that code for magit-bisect-run's
start call.
|
|
The incremental and porcelain modes of git-blame quote file names as
described in git-config's core.quotePath entry, so decode the
extracted file names with magit-decode-git-path.
Another fix would be to set core.quotePath to false when calling
git-blame, but the raw file names could interfere with parsing, and,
unlike other commands with a -z option, blame doesn't provide an
option for reliably parsing raw file names.
Fixes #4400.
|
|
|
|
|
|
|
|
|
|
magit-toplevel uses a failing `git rev-parse --show-toplevel' to
decide that it's not in a working tree. In case of corrupt Git
configuration, it will incorrectly conclude that it's not in a
repository and won't propagate the error to the user. These two
failures can't be distinguished by exit code. We can check for a
corrupt configuration with a follow-up git-config call, but it's
probably not worth doing that within the heavily used magit-toplevel.
Instead do it as part of the existing
magit--not-inside-repository-error handling as well as when an
interactive call to magit-status doesn't find a repository. This
covers magit-status, magit-status-setup-buffer, and
magit-get-mode-buffer, so it should ensure that the error is relayed
to the caller.
Closes #4337.
|
|
Alternate terms are useful for bisecting a change that conceptually
doesn't fit the default "bad" and "good" terms. Add infix and suffix
arguments to the magit-bisect transient to expose this functionality,
but hide them away by default to avoid complicating the transient for
those that don't have a use for the more general interface.
Note that unlike "good" and "bad", which are fontified with different
faces (magit-bisect-good vs magit-bisect-bad), both alternate terms
are fontified with the same face, magit-refname. While it'd perhaps
be helpful to distinguish between the refs for each term, it doesn't
seem worth the trouble to address.
|
|
Teach git-rebase-set-action to act on the lines in an active region.
This affects the set of commands that target commit lines, as well as
git-rebase-kill-line, which targets rebase lines of all action types.
For other commands that don't operate on commit lines---such as
"exec", "noop", and "merge"---it's not clear that there's any sensible
behavior for an active region, so leave those be.
Closes #4172.
|
|
Calling magit-rebase-remove-commit and selecting the HEAD commit
results in git-rebase saying "error: nothing to do" because it amounts
to commenting out the single item in the sequence to-do list.
Make it possible to remove the tip commit by tacking on a "noop"
action above the commented out "pick" line.
Closes #4195.
|
|
db97623a (magit-insert-{log,bisect-rest}: handle refs with
parentheses, 2017-04-15) introduced the first null byte in the
--format value, and since then the format string has continued to gain
null bytes. Unfortunately, this interferes with the graph prefix that
Git adds to each line of the text:
$ git log --graph 9423edc0~2..9423edc0 --format="%h%x00%ad%n%s%n"
* 9423edc0^@Fri May 22 17:42:34 2020 +0200
magit-commit-absorb: New command
|
* 1f8ee45d^@Fri May 22 17:38:12 2020 +0200
Rename magit-commit-absorb to magit-commit-autofixup
If the %x00 is replaced with another character, a "| " is appended in
front of magit-commit-absorb as well.
The visible consequence of this is a regression in the display of the
++header output when combined with --graph, where the
magit-log-revision-headers-format lines lack a graph prefix.
Restore the desired output by using a form feed instead of the null
byte.
Closes #4129.
|
|
magit-abbrev-length considers core.abbrev to be "auto" when
core.abbrev is unset (Git's default as of 2.11) but does not account
for an explicit value of "auto". An explicit "auto" is fed to
string-to-number, resulting in magit-abbrev-length incorrectly
returning 0. The main visible effect of this is misalignment in log
buffers.
Check whether core.abbrev is set to "auto".
Re: #4123
|
