| Age | Commit message (Collapse) | Author |
|---|
|
add-change-log-entry gets the file name for the entry with
add-log-buffer-file-name-function, which defaults to buffer-file-name.
When magit-diff-visit-file--noselect visits a blob rather than a
working tree file, buffer-file-name returns nil, leading to an entry
without a file name. Let-bind add-log-buffer-file-name-function to a
function that knows about magit-buffer-file-name.
|
|
Closes #4056.
|
|
When a function regexp is passed to git-log's -L option, it is parsed
up to the first colon and the rest is taken as the file name. If
magit-log-trace-definition-function returns a name that contains a
colon in it, we need to escape it.
Fixes #4051.
Closes #4055.
|
|
When calling git-read-tree to create a temporary index for the working
tree wip ref, we perform a merge in addition to a read [0]. The
advantage of doing a merge---which has been done since 59e43cbe7
(address issues concerning `git read-tree', 2015-09-11)---is
performance. When a merge is specified for a single tree, as is the
case here, it means "copy over the index's stat info for paths that
match between the tree and the index". So, our newly constructed
temporary index is populated with the stat info from the main index
for unchanged paths, and we benefit from a warm start for Git's stat
comparison optimization.
However, doing a merge means that we a susceptible to a read-tree
failure that reports
error: Entry '<file>' not uptodate. Cannot merge
when some of the index entries are marked with "assume unchanged" or
"skip worktree" bits. In particular, the problem arises when one of
the marked entries in the main index differs from a file in the wip
working tree ref. The easiest way for this to happen is (1) the user
changes and saves an unmarked file in the working tree, (2) marks the
file with "assume unchanged" or "skip worktree", and (3) changes and
saves the file again.
Pass -i to read-tree, which disables the up-to-date check. This
should be fine to do given that we're writing to a temporary index and
that, as explained above, we're using a single-tree "merge" rather
than the merge of HEAD and another tree for which the check is
relevant.
Re: #4037
[0]: We do so with --reset rather than -m, but we specify only a
single tree, so the behavior is the same.
|
|
404bd1148 (magit--wip{,-index,-wtree}-ref: New functions, 2018-08-02)
introduced magit--wip-ref to handle the construction of wip refs. For
a detached head, the wip ref should be ".../{wtree,index}/HEAD".
magit--wip-ref returns the correct wip ref for a detached HEAD when
REF is nil. However, it incorrectly constructs the ref as
"{wtree,index}/refs/heads/HEAD" when "HEAD" is passed as REF. As a
result, commits for a detached HEAD are made on
"{wtree,index}/refs/heads/HEAD".
Add a condition to magit--wip-wtree-ref to avoid treating a REF of
"HEAD" as a regular branch.
|
|
|
|
|
|
As of Git 2.19.0, specifically 0231ae71d3 (diff: turn
--ita-invisible-in-index on by default, 2018-05-26), `git diff`
(without --cached) displays intent-to-add files as new files rather
than empty files. This breaks staging a region from an intent-to-add
file: when magit-stage derives a patch based on this output and feeds
it to `git apply --cached`, it fails because the intent-to-add file
_is_ already in the index.
Work around this by passing --ita-visible-in-index when we insert
diffs, restoring the pre-2.19.0 default behavior. Note that we can't
pass this flag unconditionally because it isn't available until Git
2.11.0. As suggested by Jonas in gh-4026, it's safe to cache the
value to limit the cost of this version check to one additional git
call per session as opposed to an additional git call per
magit--insert-diff call. The worst case scenario is the unlikely
event that the user upgrades to 2.19.0 or later during a session, in
which case intent-to-add staging (a relatively obscure feature) won't
be available for that session.
Fixes #4026.
|
|
magit-copy-buffer-revision, and magit-copy-section-value when
appropriate, pushes the full revision hash to magit-revision-stack and
the kill ring. If callers would like to use this to insert an
abbreviated hash, their main options are either to
(1) yank the full hash and truncate it manually or (2) configure
magit-pop-revision-stack-format accordingly and call
magit-pop-revision-stack.
Offer an option to put the abbreviated hash on the kill ring and the
magit-revision-stack.
|
|
|
|
Stage the modified subdirectory .gitignore, not the top-level
.gitignore.
|
|
The dropped entry is already covered by another entry.
|
|
In the magit status buffer, move the point over an untracked directory, that
is, a directory with only (and at least one) untracked files. Pressing "ip"
to add an ignore rule should probably suggest that directory. This commit
makes it so.
Previously only untracked files were suggested, and globs of files
with the same extension as untracked files. This extends the
gitignore suggestions by adding untracked directories.
Modified-by: Kyle Meyer <kyle@kyleam.com>
|
|
|
|
|
|
|
|
Closes #3943.
|
|
(magit-status-here) is in C-c M-g g; C-C M-g s is (magit-stage-file).
|
|
|
|
Allow specifying arbitrary flags and predicates in custom order.
With the default value of magit-repolist-column-flag-alist, this is
fully backward compatible with the original magit-repolist-column-dirty,
which is also preserved as an obsolete function alias.
|
|
Previously this visited to the file in the working tree. There was
no way to visit the HEAD blob instead. The HEAD blob is the last
blob that still contains the removed lines and going there is useful
because it allows blaming those lines.
Users who don't like this can set `magit-diff-visit-avoid-head-blob'.
Re #3848.
|
|
Applying context-free patches can lead to unintended and confusing
results. The ability to stage a context-free hunk doesn't provide any
functionality that isn't better achieved another way (e.g., staging a
region within a hunk), so let's move magit-apply-region's guard
against context-free patches into magit-apply-patch.
Closes #3924.
|
|
|
|
When applying a hunk or a region of a hunk that is not the first hunk
from the file, the line number in the header for the new start
position will often be incorrect because it accounts for content of
the ignored hunk(s) from above. This usually isn't problematic
because there is enough context for 'git apply' to locate the
appropriate spot, but, in some cases where the context is too
repetitive to identify the location, it can lead to incorrect staging.
Note that the problem here is simpler than the one that 'git add -p'
needs to solve because, due to Magit's restrictions on what makes a
valid selection, we know that the hunks are contiguous and from the
same file.
Re: #3924
|
|
* Continue to use only `face' for strings that will be used by
Transient, and for `read-char-choice' prompts.
* Also leave `git-commit-propertize-diff' along because it already
does face/font-lock-face conversion at runtime.
* Otherwise when returning a string use `face' AND `font-lock-face'.
This is done using the new functions `magit--propertize-face' and
`magit--put-face'.
|
|
|
|
|
|
|
|
|
|
The default value of magit-view-git-manual-method has always been
`info', although it was incorrectly documented as nil until eb6d8bde3.
Adjust Info-follow-nearest-node--magit-gitman to treat `info' rather
than nil as a valid value.
Closes #3873.
|
|
|
|
When deleting a remote ref fails, we fall back to removing the local
remote-tracking ref because a common reason for the push to fail is
that the ref no longer exist on the remote. But it may fail for other
reasons (e.g., can't connect to the remote or a non-zero exit of the
pre-receive hook), and we shouldn't remove the local tracking ref in
these cases.
One way to tighten the check would be to search the process buffer for
"unable to delete 'BRANCH': does not exist". (We'd need to search for
each ref with a tailored message because we wouldn't want to remove
the remote-tracking refs for multiple refs when the push failed
because one ref does not exist.) This method relies on the message
being stable and wouldn't work for some users because that message is
marked for translation.
Instead reach out to the remote to get a list of its branches, and
check the ref against this list. Doing so adds an expense, but it
seems like an acceptable one given that the check is performed only on
failure and that it replaces cases where the user would need to
manually call 'git fetch --prune REMOTE' to clean up otherwise.
Although not strictly necessary, narrow the check to the specific
error code that we expect to see for the "no longer exists" failure.
The exit code for a failed connection is different, so this avoids
trying to connect to the remote with magit-remote-list-branches when
the push already failed to connect.
Fixes #3650.
|
|
Let the user configure which ugliness they prefer when showing a
commit from a log that uses --follow: empty diffs or ignoring the
log's file restriction.
Closes #3680.
|
|
The infix argument is on level 5 of the diff transients for now. It
has to be made available by the user for each transient using "C-x l".
For now the colors specified in `ansi-color-map' are used.
Closes #3424.
|
|
Git v2.2 was released more than four years ago.
I announced a long time ago that I would drop support even for
versions before v2.4. I dropped support for versions before
v2.0 more than half a year ago and nobody complained about it.
Even Debian stable has v2.11 now, and while Debian oldstable
only has v2.1, v2.11 is available from jessie-backports.
|
|
|
|
|
|
|
|
Teach magit-copy-section-value how to remove diff markers to help
users copy usable snippets from hunks. Note that this won't work well
for combined diffs because it only removes the outermost column.
Re: #3716
|
|
|
|
|
|
The interactive form and args did not match up, so using a prefix
interactively did not cause the ident to be displayed, but rather the
vector (which is not useful for magit-status-initial-section).
|
|
The previous approach that tried to outsmart Imenu was broken.
Fixes #3691.
|
|
Closes #3676.
|
|
|
|
Otherwise Git would fail for an empty commit, making the false claim
that "You asked to amend the most recent commit, but doing so would
make it empty", which isn't true because this would *keep* it empty,
as it was before.
|
|
Fixes #3685.
|
|
Closes #3692.
|
|
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.
|
|
Fixes #3686.
|
