| Age | Commit message (Collapse) | Author |
|---|
|
Unless `focus-on-ref' is a member of `magit-visit-ref-behavior', the
prefix argument was simply passed along to `magit-show-commit', which
was inconvenient because that then prompted for the commit to show
instead of just showing the commit at point (tag or tip of branch).
Now we drop the prefix argument before calling `magit-show-commit',
but only if that command would not have been called without a prefix
argument anyway.
Closes #3009.
|
|
,----
An added line like |<tab-><tab->text
should be displayed in a diff as |+<tab-><tab->text
but the display engine turns it into |+<tab><tab->text
`----
We have to set the `:width' of each leading tab individually to
prevent that.
Closes #3185.
|
|
To show the history of removed files one has to use `--full-history'.
When showing the history for a single such file use that argument,
else not a single commit would be shown. This can also results in
many unrelated merge commits being shown, which is why we don't use
this argument all the time, but in this special case that noise is
still preferable to nothing.
Closes #3012.
|
|
|
|
|
|
|
|
|
|
Closes #2927.
|
|
In some cases it is actually preferable to continue to offer that as
the default, in which case this command continues to do so. In some
other cases the current branch might continue to be the default even
though that isn't optimal.
Closes #2924.
|
|
Remember visibility when switching from showing unpushed commits
to showing N recent commits. Normally visibility is automatically
preserved based on the section identity, but here we have to do it
explicitly because the section identity changes.
Closes #3147.
|
|
Previously recent commits were only shown when they had not been pushed
to the upstream yet. `magit-insert-unpulled-from-upstream-or-recent'
allowed showing recent commits more often, but it is strange that this
functions behavior depended on whether there were unPULLED commits.
Replace that function by one that falls back to displaying recent
commits if there are not unPUSHED commits instead and use that in the
default value of `magit-status-sections-hook'. To avoid breakage
define an alias for the old function.
|
|
All three methods for retrieving the old branch name
interactively (magit-local-branch-at-point, magit-get-current-branch,
magit-read-local-branch) return a qualified branch
name ("heads/<branch>") if a tag has the same name. Strip this prefix
from the name passed to "git branch (-m | -M) <oldbranch> <newbranch>",
which only accepts an unqualified name for <oldbranch>.
Fixes #3222.
|
|
|
|
Closes #3146.
|
|
Make those actions child sections of the respective commit section to
keep it possible to select neighboring commits and to allow hiding the
exec actions.
Closes #3003.
|
|
Closes #3011.
|
|
Closes #2935.
|
|
Closes #2950.
|
|
Closes #2940.
|
|
|
|
|
|
This patch introduces a new programmer variable (i.e., not exposed via
Customize) `magit-buffer-lock-functions'. See the docstring for the
full structure and specification of this variable, but it allows
third-party modes (say, Magithub) to create entirely new magit-mode
buffers that are locked to a value.
|
|
Closes #3179.
|
|
This takes recent additions into account but also improved the
descriptions of features that already existed for a long time.
|
|
The addition of this command makes it necessary to change the key
binding for `magit-blame-popup' in a few places, where "b" was used
before and "B" is used now.
Doing so allows moving through history using "b" and "f", if kept
`magit-blame-popup's old binding then we would have to use "b b" and
"f", which would be inconsistent. Furthermore in `magit-blame-popup'
"b" was already bound to `magit-blame' and "B" to `magit-blame-popup,
which in turn is consistent with the other bindings in that popup.
It would be nice if we could rearrange `magit-file-popup' some more,
but due to limitations in `magit-popup' that is not possible at this
time.
Closes #3055.
|
|
Due to limitations in `magit-popup', we have to make some compromises
in how the various actions are presented in the popup buffer. Longer
action descriptions would be nice, but would mess up column spacing.
|
|
When performing an instant fixup it is clearly a mistake to select an
unreachable commit. The second step, the rebase, would always fail.
However creating a fixup commit for an unreachable commit without
trying to instantly rebase is a valid use-case, it allows "labeling"
the fixup as belonging to some commit. Just doing a rebase would not
be enough to get the fixup to the right place, but we cannot know
whether the user is aware of that - so continue to allow the creation
of such fixup commits.
|
|
Give the user the opportunity to abort or select another
commit before the fixup commit has already been created.
Closes #3176.
|
|
|
|
|
|
When uniquifying buffer names, then it is not possible to append an
asterisk, due to limitations in the `uniquify' package. But when that
is disabled, then we can.
Closes #2841 and #2334.
|
|
|
|
Closes #3104.
|
|
|
|
These commands behave differently from `{previous,next}-line' inside
hunk bodies when using shift-selection. Here it is necessary to not
move point in order to select a single line - the vanilla commands
cause the region to contain one line by moving one line, but as far
as Magit-selection is concerned that would select two lines. #2912
|
|
Don't rely on the "Commands:" heading to detect the command section
because this can vary depending on $LANG. Instead detect the line for
the first command (i.e. "p, pick"). There's no guarantee that this
output is stable but (1) the same is true for all interactive rebase
help output and (2) this text has not changed since the introduction
of interactive rebase. Also, don't assume that each command and its
description are separated by "=" (e.g., "p, pick = use commit")
because some translations use a different separator.
The resulting output is a little odd in that it mixes English from
git-rebase-command-descriptions with Git's help in $LANG. Another
option would be to force the entire rebase buffer to be in English by
setting LANG/LC_ALL (e.g., in magit-rebase-interactive-1). Until we
decide that that's a direction we want to go, let's use this fix to
avoid displaying inaccurate bindings in rebase buffers with translated
text.
Fixes #3175.
|
|
|
|
|
|
Fixes #3163.
|
|
|
|
As of Git 2.13.0 (c10388c7dc), the file for editing a branch's
description is named "EDIT_DESCRIPTION" rather than
"BRANCH_DESCRIPTION".
Fixes #3149.
|
|
Bind --no-verify to "h" in the commit popup for consistency with the
push and commit popups. Also, change its description to match the
other popups' descriptions.
|
|
The --no-verify option is available for three git commands: push,
commit, and rebase. The push and commit popup include --no-verify;
let's add it to the rebase popup as well.
Closes #3142.
|
|
|
|
Previously it expected a function that returns one end of the range
(the other end always being the current branch). Callers used to
pass either `magit-get-push-branch' or `magit-get-upstream-ref' as
that argument.
These functions have the advantage of returning nil if the respective
branch is not configured or does not exist, which in turn meant that
we did not end up calling `git log ...' only to learn that that log
is empty and then having to cancel the respective section.
However calling these functions is much more expensive than calling
`git log ...' and then possibly having to cancel.
For `@{upstream}' this change is un-problematic because that always
refers to exactly one branch or no branch at all. The meaning of
`@{push}' however is overloaded and can refer to multiple branches,
or an unintended branch (for our use).
As far as I can tell (see `gitrevisions(7)'), the only variable that
affects this is `push.default', so to make sure `@{push}' works as
expected we have to use `git -c push.default=current log ...'.
Because of this issue the respective module section headings used to
mention "<push-remote>" but now the mention "@{push}", like other
headings mention "@{upstream}". In this context ("show the one and
only push target of the current branch"), we force `git' to use a
meaningful value. In other contexts, e.g. `git push' with no
arguments, that would be dangerous. Here it is not, and it is also
not misleading because Magit never does `git push' with no arguments.
(It is possible to do so, but users have to explicitly opt-in to that
dangerous behavior.)
|
|
|
|
|
|
magit-revision-toggle-file-filter toggles the file restriction in
revision buffers. Replace this command with a command that works with
all diffs. Like the previous command, the command operates on the
revision buffer if it's called from a log buffer.
Re: #3132
|
|
Theory of operation:
* When the user requests a bookmark for the current buffer and it’s in
one of the supported modes, our ‘*-make-record function’ will be
called.
* It will create a bookmark record using the default function, set its
‘filename’ property to the root of the current repository, ‘handler’
to the corresponding ‘*-jump’ function, and various ‘magit-*’
properties to parts of ‘magit-refresh-args’.
* When the bookmark is activated, it is passed to its recorded handler
function, which feeds the saved ‘magit-*’ properties into the
relevant Magit command and restores the position in buffer.
* The handler functions are marked autoload so that they pull us in
when the user activates a bookmark even if neither ‘magit-bookmark.el’
nor ‘magit.el’ have been loaded yet.
* Otherwise, we get loaded after both ‘magit.el’ and ‘bookmark.el’ are
loaded, which is the necessary condition for the user to start
creating bookmarks.
|
|
As mentioned in git-reset's manpage, ORIG_HEAD can be useful for
undoing a commit and reusing its message (though there are of course
other ways to do this). Define a reader for the --reuse-message
option that offers ORIG_HEAD as the default value when it exists.
Also, prompt with all ref names. If these aren't useful for the given
situation, the user can ignore them and enter an arbitrary value.
Closes #3110.
|
