| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
|
|
|
|
The release was indeed tagged on the 8th,
but the announcement wasn't ready until the 9th.
|
|
|
|
|
|
magit-diff-range with a single revision and magit-diff-working-tree
both show a diff between the revision and the working tree. Whether
magit-reverse aborted in these buffers used to be determined by
whether the specified revision resolved to HEAD. If so, magit-reverse
aborted with "Cannot reverse unstaged changes".
magit-reverse aborting here wasn't entirely right because a diff of
HEAD versus the working tree may contain staged changes too.
e94b6ebf (Record diff-type in magit-diff-mode buffers, 2023-03-18)
moved magit-diff-range and magit-diff-working-tree in different
directions. With that change, magit-diff-range with any revision,
including HEAD, allows reversing. On the other hand,
magit-diff-working-tree with any revision forbids reversing.
Update magit-diff-working-tree to pass `committed' instead of
`unstaged' for the diff type. As a description, `committed' is a bit
off (the diff can include a mix of unstaged, staged, and committed
changes), but it allows reversing and matches what magit-diff-range
does.
For a diff of any revision against the working tree, magit-apply is
bound to fail. Before e94b6ebf, magit-apply used to abort when the
diff was between _HEAD_ and the working tree. After e94b6ebf and this
change, magit-apply leaves the failure to git-apply. To abort early,
we could mark working tree diffs with a distinct diff type, but
leaving the failure to apply time is good enough, at least for now.
Closes #5090.
|
|
|
|
|
|
|
|
|
|
As of Magit v2.90.0, magit-bisect-start aborts if the revisions are
flipped or there are uncommitted changes. magit-bisect-run shared
those guards at the time because it used magit-bisect-start
underneath, but f592e367 (magit-bisect-run: Don't start bisect
asynchronously, 2021-06-20) moved away from magit-bisect-start,
unintentionally losing the checks.
Restore the checks by extracting them to a shared helper.
Closes #5070.
|
|
magit-insert-am-sequence inserts a section for all patches in
$GIT_DIR/rebase-apply/ and then displays ORIG_HEAD through HEAD via
magit-sequence-insert-sequence. If the 'git am' call fails to apply a
patch, this leads to repeated sections for successfully applied
patches because Git leaves the patch files around after successfully
applying a patch.
Avoid the repeated sections by explicitly inserting a section only for
$GIT_DIR/rebase-apply/ patches that have not been applied, leaving the
rest to the magit-sequence-insert-sequence call.
Closes #5024.
|
|
We already do this in Transient's documentation because that's what
is being done in Emacs' documentation and Transient is part of Emacs.
Let's be consistent even at the cost of making the English unhappy.
Also add a comma before "e.g." and "i.e.", if not inside parentheses,
which is the correct thing to do, regardless which style guide one
chooses to follow.
|
|
|
|
magit-commit-at-point and magit-branch-or-commit-at-point extract the
commit from a blame chunk with
(magit-current-blame-chunk 'addition t)
For a magit-blame-reverse chunk, 'git blame' is called again to get an
'addition' chunk, leading to the returned commit confusingly not
matching the chunk's commit. A downstream consequence of this is that
magit-show-commit displays the addition commit for a removal chunk
(while magit-diff-show-or-scroll-up shows the expected removal commit,
because it doesn't rely on magit-branch-or-commit-at-point).
As of 4b8eab3a (magit-{branch-or,}commit-at-point: Only use blame
chunk when blaming, 2022-05-27), magit-commit-at-point and
magit-branch-or-commit-at-point invoke magit-current-blame-chunk only
when Blame mode is enabled, so it's safe to assume that there is an
existing blame chunk. Rely on it to get the appropriate commit.
Fixes #4834.
|
|
Commands that depend on optional third-party Git extensions use
executable-find to check whether the extension is available. That
misses the legitimate case where an extension is installed in Git's
exec path rather than a directory in $PATH.
Update these spots to call a new helper that looks in Git's exec path
before calling executable-find. Note that the order is chosen to
follow Git's precedence (though that doesn't matter for any of the
current callers because they don't use the return value).
Closes #4812.
|
|
This action is new in Git 2.38.
Closes #4776.
|
|
This patch permits `magit-clone-url-format' to be represented as an
alist mapping hostnames to URL formats. This way Magit can be
configured to translate repository names into URLs when using servers
that employ different URL schemes. The current value type (string) is
kept for backwards compatibility.
|
|
By setting magit-log-merged-commit-count.
|
|
|
|
When I am undecided whether to mention a certain commit, then
represent it with a line of the form "HASH SUMMARY" for now.
|
|
magit-diff-visit--hunk detects mode change hunks (and returns nil) by
checking if the section has no value. However, since fa804439
(Restore ability to apply header hunks individually, 2021-07-12),
chmod hunks have a non-nil value. Update the condition.
Fixes #4623.
|
|
magit-sequencer-continue signals a user error if there are any
unstaged changes. However, that's stricter than the behavior of 'git
cherry-pick --continue' and 'git revert --continue', which are okay
with unstaged modifications in files without conflicts.
To support this behavior, one option would be to drop the guard
entirely and let 'git (cherry-pick|revert) --continue' do the error
reporting. However, the reason the Lisp error was added in the first
place was in response users reporting these Git failures as a bug.
So instead signal a user-error if there are unmerged files. It's
possible that this narrower condition lets through a few rare cases
that trigger a '(cherry-pick|revert) --continue' failure, but those
are hopefully uncommon enough that they won't prompt bug reports.
Closes #4615.
|
|
7fee4089 (Refactor commands that can set the push-remote before their
main task, 2019-03-29) switched magit-pull-from-pushremote to using
magit-run-git-async instead of magit-run-git-with-editor (likely a
copy-paste error from magit-push-current-to-pushremote). Go back to
using magit-run-git-with-editor because, when pull is configured to
merge, Git will pop up an editor for non-fast-forward merges.
Fixes #4604.
|
|
Merging two lines that both renamed a file leads to a conflict like
this:
DD f
AU f-rename
UA f-rename-side
In the status buffer, that shows up as three staged entries:
Staged changes (3)
unmerged f (both deleted)
unmerged f-rename (added by us)
unmerged f-rename-side (added by them)
For conflicts in the staged section, calling magit-discard to trigger
magit-discard-files--resolve/magit-checkout-stage is useful for
letting the caller choose a side's variant. However, that doesn't
work for the entries above:
* On the first entry, magit-discard-files--delete is called rather
than magit-discard-files--resolve/magit-checkout-stage, and it
fails trying to delete a working tree file that isn't there.
* On the second and third entries, calling magit-discard does go
down the magit-discard-files--resolve/magit-checkout-stage path.
That works as expected when choosing the side with the file in its
tree (e.g., choosing "ours" for f-rename above). However,
choosing the other side leads to the 'git checkout --ours/theirs'
call failing because the file doesn't exist on that side.
Fix magit-discard on the first entry by sending DD entries to
magit-discard-files--resolve rather than magit-discard-files--delete.
Asking the caller to choose a side is a bit odd because either side is
equivalent, but it's probably an uncommon enough case that it's not
worth adding dedicated handling for it.
Fix magit-discard on the second and third entries by teaching
magit-checkout-stage go down the 'git rm' path if it sees UA/AU for
the side the does not have the file in its tree.
Fixes #4225.
|
|
Git gained partial clone support via its --filter argument in v2.17
(undocumented until v2.27.0). Add the option to the clone transient,
along with a custom reader that offers the two mostly likely values of
interest (blobless and treeless clones). See git-rev-list's manpage
for a complete description of the filter specification.
Note that users should probably expect to hit into rough edges when
working with a partial clone. For example, without a connection,
checking out a commit for which blobs need to be downloaded will
"fail" in the sense that it the checkout command will emit errors and
`git status' from the command line will show deleted files for files
that couldn't be downloaded. While that's not surprising, the
checkout command has an exit status of 0 [*], so Magit users won't see
an indication of the failure. And worse, the deleted files won't show
up in the status buffer because the underlying git-diff commands fail
(for the same reason as the checkout: the required objects can't be
downloaded).
[*] I haven't yet reported this upstream, but it seems like a bug to
me.
|
|
When the goal is to do a sparse checkout after cloning a repo, it's
possible to avoid checking out undesired files on the initial clone:
$ git clone --no-checkout ...
$ git sparse-checkout init --cone
$ git checkout $BRANCH
Doing that probably isn't very common, so it's tempting to add
--no-checkout to the magit-clone transient and then let users handle
the sequence themselves. However
* it seems unlikely that many people would remember that sequence
* those steps don't work well in Magit because, after the `clone
--no-checkout` step, refreshing the status buffer will get hung up
on all the "deleted" files. That's true even with a repo of
normal size, but it seems reasonable to expect larger target repos
in the sparse checkout context.
Add a dedicated command that hooks into magit-clone-internal to enable
a sparse checkout before a refresh is attempted.
|
|
Git has had limited and mostly hidden sparse checkout support for a
long time, but Git 2.25 exposed the functionality via a porcelain
command. Alongside this, it added and promoted a restricted pattern
set ("cone mode") that improves the performance of the sparse
checkouts, particularly with large trees.
Add a new library that provides an interface to 'git sparse-checkout',
supporting only the new cone mode.
Bind magit-sparse-checkout to ">" in magit-mode-map. Aside from the
lack of available letters, this key choice is based on the (perhaps
silly) hope that ">" will be easy enough to associate with a command
that converts the working tree from a bigger checkout to a smaller
one.
Hold off on adding a binding to magit-dispatch given that
magit-dispatch is mostly limited to letters at the moment and
magit-sparse-checkout is unlikely to be a heavily used command.
Note that magit-sparse-checkout-{set,add} read directories with
magit-completing-read-multiple*, which means that directory names
can't include crm-separator characters. However, this same limitation
is already in place for magit-read-files/magit:--.
|
|
magit-stash-drop has let-bound helm-comp-read-use-marked around its
magit-read-stash call since 53f7cfe6 (magit-{tag-delete,stash-drop}:
Supports Helm's marked candidates, 2020-08-29). However, soon after
that commit, magit-read-stash's processing became incompatible with
reading multiple items rather than one: 7f7c3aa4 (magit-read-stash:
Show the commit messages while reading, 2020-10-20). The result is
that Helm users see a type error when they call magit-stash-drop from
the "Stashes" section.
Fix the error by removing support for marking multiple candidates.
Instead it'd be possible to adjust magit-read-stash to handle multiple
items, but
* that's too much special handling for one completion framework.
The goal with 53f7cfe6 was just to add support for Helm's
multi-item completion in the spots where it worked with the
existing code and didn't complicate things on Magit's side.
* it's unlikely that dropping this functionality affects any users
because it was broken within a couple months of being added, never
made it into a release, and has been broken for over a year.
Fixes #4571.
|
|
|
