| Age | Commit message (Collapse) | Author |
|---|
|
|
|
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.
|
|
|
|
Bind it in `magit-log-refresh-popup' and for modes where that popup
isn't used replace `magit-toggle-margin's binding with a new popup
`magit-margin-popup'.
|
|
Currently we only use the margin to display additional information
about commits, but that will likely change, not least to avoid wasting
space. Since the format of the margin-format options changes in the
upcoming release anyway, we should take this opportunity to make the
format forward compatible and thereby avoid a similar breaking change
in the future.
The old format
(INIT NAME DATE-STYLE)
isn't suitable, we now use
(INIT STYLE WIDTH AUTHOR AUTHOR-WIDTH)
(AUTHOR and AUTHOR-WIDTH replace NAME. It is now possible to
specify how much space should be used for the name, provided
it is shown at all, without also showing it initially. WIDTH
is an addition.)
or at least that's what's being displayed in doc-strings, conceptually
the format is
(INIT STYLE WIDTH DETAILS DETAILS-WIDTH)
The same format is used for a buffer-local variable
`magit-buffer-margin'. Here the meaning of INIT changes to ENABLED.
This variable replaces `magit-show-margin', which said whether the
margin was enabled and several other variables, which were used to
cache values. `magit-buffer-margin' on the other hand also caches
other information, which may be changed on a per-buffer basis.
`magit-set-buffer-margin' no longer calculates the width of the margin
itself, instead it uses WIDTH. The option's WIDTH can be a function
whose value is then stored in `magit-buffer-margin's WIDTH. For logs
this is always the new `magit-log-margin-width' function. Due to the
mentioned forward compatibility this has to be exposed in the user
interface even though users should never change that for now.
There's still one hardcoded part: `magit-margin-option' returns the
option suitable for the current buffer based on a constant list. But
that can easily be addressed when the need arises.
|
|
|
|
BODY may contain calls to git that are identical to outside calls
during the same refresh, but which are expected to return a different
value due to the sue of a different index.
Do the same in `magit-sequence-insert-sequence' around the calls to
`magit-commit-tree' and `magit-commit-worktree'. This isn't required
at present, but if other places start calling `magit-commit-tree'
during a refresh and outside of `magit-with-temp-index', then this
would become necessary.
Re #2883.
|
|
Each rev, not some constant commit, has to be compared with the last
applied commit.
Fixes #2877.
|
