| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
Git v2.11 introduced the notation "rev^-n" as a short-hand for
"rev^n..rev". Teach magit-diff-refresh-buffer to detect such ranges
(including "rev^-", where the unspecified n defaults to 1) so that the
diff buffer header does not falsely report that the diff is between
"rev^-n" and the working tree.
|
|
If you do a rebase and drop all the commits in the file, git will
do nothing, because the file is considered empty (everything is
commented). If you really do want to remove all the commits, you
have to insert a noop action which prevents the file from being
empty. It has no other purpose.
|
|
magit-toplevel needs to determine the working tree from inside .git/
when a buffer is visiting COMMIT_EDITMSG or various other files. To
do this, it uses the following logic:
1) file is in .git/modules/<module>/: set working tree to the output
of "git rev-parse --show-toplevel"
2) file is in .git/worktrees/<wtree>/: set working tree to the path
in .git/worktrees/<wtree>/gitdir, minus the trailing "/.git"
3) file is in .git: set working tree to the parent directory
This, however, fails when a repository was set up by passing
--separate-git-dir to "git init" or "git clone", following step 3 to
return an unrelated parent directory [*].
The most visible consequence of magit-toplevel failing to return the
working tree for separated gitdirs was that an empty diff buffer was
displayed while committing (issue #2955). 9e0e2a24 (While committing,
diff from inside gitdir if necessary, 2017-01-17) worked around this
by introducing a defvar that could be let-bound to instruct
magit-toplevel to return the gitdir instead. This resulted in the
diff buffer correctly showing staged changes because "git diff
--cached" works fine from the gitdir, but it broke
magit-diff-visit-file in these buffers (issue #2981) because the
default directory was the git directory rather than the top-level of
the working tree. This approach also didn't consider other cases
where magit-toplevel would fail inside a separated gitdir, such as
running git-rebase-show-commit in a git-rebase-todo buffer.
Instead, let's record the worktree -> gitdir mapping of separated
repositories before the git call in magit-run-git-with-editor. When
magit-toplevel is called from a gitdir file (COMMIT_EDITMSG,
MERGE_MSG, git-rebase-todo, ...), it can look for a working tree
associated with the current git directory. If one isn't found, it can
take the parent directory as the working tree, as usual. This comes
at a price of a magit-toplevel and magit-git-dir call during editing
commands, but it seems unlikely that any solution could avoid these
calls.
This should cover all cases where Magit throws users into a buffer
inside the git directory, making it unlikely that magit-toplevel uses
an invalid mapping. A user would have to call a command that involves
magit-run-git-with-editor and then, before finishing that process, go
to another working tree that points to the same git directory and
again call a command that involves magit-run-git-with-editor. And the
user would have had to set up these working trees outside of the "git
worktree" mechanism because magit-toplevel handles "git worktree"
directories fine.
Fixes #2955.
Re: #2981.
[*] In Git version 2.8.4 and lower, core.worktree was set when
--separate-git-dir was used, so "git rev-parse
--show-toplevel" (step 1) would also work for separated git
directories. However, it turns out that Git was not intentionally
setting core.worktree here:
https://public-inbox.org/git/87h94d8cwi.fsf@kyleam.com/T/#u
|
|
|
|
As of d7fcc92e (magit-abbrev-length: handle auto-sized default length,
2016-12-01), magit-abbrev-length returns 0 when called within an empty
repository or outside of a repository.
Update magit-abbrev-length to instead return 7 for these edge cases.
This value is both compatible with the default length prior to Git
v2.11 and matches the auto-sized default length that Git v2.11
calculates for a fresh repository.
Whether magit-abbrev-length should return nil or a hard-coded value
when called outside of a repository is less clear, but returning a
hard-coded value has the advantage of not requiring additional steps
to determine whether we're in a repository. And returning 7 when
outside of a repository is consistent with the return value of
magit-abbrev-length before d7fcc92e.
|
|
magit-cherry-pick-popup: Make "--mainline" be an option (not a switch).
Also fix typo: "Reply" should be "Replay".
magit-cherry-pick, magit-cherry-apply: Do not 'assert one parent' if the
--mainline option is present.
|
|
|
|
|
|
|
|
|
|
When the revision or stash buffer already showed the requested
reference, but that reference no longer pointed at the same revision,
then the buffer was scrolled instead of updated. Now we save the
revision hash and compare that too.
Fixes #2966.
|
|
If a repository is created using `git init --separate-git-dir', then
that does not set `core.worktree' (unlike what `git submodule' does).
When committing inside such a repository `magit-commit-diff' is run
inside the gitdir, and there is no way to prevent that. Luckily `git
diff' also works inside the gitdir, but because many other commands
don't, we always run everything in the working tree.
This is fairly deeply ingrained, so we have to add a kludge to
`magit-toplevel', that causes it to return the gitdir instead,
and that is triggered by dynamically binding the new variable
`magit-toplevel--force-fallback-to-gitdir' to a non-nil value.
And `magit-commit-diff' now does so to fix #2955.
|
|
|
|
When the current branch is renamed, the entry for this event in HEAD's
reflog has an empty message [1]. The empty message causes issues for
magit-log-reflog-re, which will match beyond the current line to find
the "refsub".
As an example, the raw output
86904ee5^@Kyle Meyer^@HEAD@{1484792543 -0500}^@
86904ee5^@Kyle Meyer^@HEAD@{1484791872 -0500}^@commit (amend): msg
c17b5061^@Kyle Meyer^@HEAD@{1484791742 -0500}^@commit (amend): msg
is washed to
86904ee5 0
86904ee5^@Kyle msg
86904ee5 1 amend msg
c17b5061 2 amend msg
instead of
86904ee5 0
86904ee5 1 amend msg
c17b5061 2 amend msg
To handle these lines, tighten magit-log-reflog-re so that it doesn't
allow the refsub to match newlines, and teach magit-log-wash-rev to
insert the reflog count even when refsub has a nil value.
Although these mostly blank lines aren't very informative, it's
probably worth retaining them in order to be consistent with the "git
reflog" output and to avoid users being confused about why entries are
missing.
[1] I'm not sure if this is intentional. I've asked the Git mailing
list: https://public-inbox.org/git/87pojmwq5y.fsf@kyleam.com/
|
|
The functions `magit-get-upstream-branch' and `magit-get-push-branch'
recently gained a second optional argument VERIFY. That is a problem
because the default value of the existing first argument, BRANCH, was
defined using `cl-defun's (VAR INITFORM) format. The value of the
INITFORM, which is (magit-get-current-branch), is only used when the
VAR isn't provided by the caller at all. If the VAR is provided, but
`nil', then that provided value `nil' is used.
Previously it wouldn't have made much sense to use (FN nil), but now
it is reasonable to use (FN nil t) and expect the default to be used.
But actually one had to write (FN (magit-get-current-branch) t) until
before this commit.
But that clearly is very cumbersome, and so we stop using `cl-defun'
and instead, if necessary, determine the default value inside the body
of the affected functions.
For consistency, we do the same thing for `magit-get-upstream-ref',
`magit-get-upstream-remote', and `magit-get-push-remote', even though
these functions (currently) do not take a second optional argument.
Fixes #2960.
|
|
Fixes #2917.
|
|
|
|
|
|
|
|
Closes #2907.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Adjust the default values so that they match the documentation and
what is expected by the Custom type of these options. Funny enough
the code which uses these options can deal with both the old wrong
value and the value because it uses `-flatten' to turn an alist into
a plist. Now the value isn't an alist anymore but a function whose
first and only member is an alist, but that works too and I don't
change it so that old customized values that use the wrong format
continue to function too.
|
|
|
|
|
|
|
|
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.
|
|
|
|
In cases where the passed revision and a file were ambiguous, the git
call silently failed, leading to the reflog buffer incorrectly
reporting an empty reflog for the revision.
|
|
Fixes #2865.
|
|
|
|
|
|
Re: #2890
|
|
Re: #2890
|
|
Re: #2890
|
|
|
|
|
|
|
|
Re #2886.
|
|
|
|
|
|
I am adding the introduction to release notes, because whenever
someone makes a release without such an introduction, then someone
points out on social media that it is missing ;-)
I always intended to purge those introductions eventually, but never
did because they don't do any harm either. But now I noticed that the
url to the homepage is no longer correct (http instead of https) and
so I would have to touch those files anyway...
|
|
Set `magit-section-highlight-overlays' to nil in addition to mapping
delete-overlay over it to remove all references to those overlays.
Otherwise `magit-section-highlight-overlays' grows unbounded.
|
