| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
When "Untracked files" has not been expanded yet, then its children
slot is nil, for performance reasons. For this section most callers
treat the returned value as a boolean, so just return t instead.
One caller, which did not treat the value as a boolean, has to be
adjusted.
Closes #5366.
|
|
Inserting rebase actions into the status buffer when --rebase-merges
is specified triggers two errors with the v4.3.3 release:
1) a type error due to empty lines in the todo list
2) an unbound slot error due to misalignment between the abbrevs list
returned by 'git log --no-walk --format=%h <commit>...' and the
input commits
The first was resolved a few commits back with 621e69eb
(magit-rebase-insert-merge-sequence: Skip over empty lines).
The second error is avoided by 4fc60fdb (magit-rebase--todo: Deal with
duplicated commits). The new logic requests that the git-log call
also output the full hash so that abbrevs can be used as an alist
mapping a long hash to an abbreviated one. But the output lines are
not actually split from the '%H %h' strings into alist entries, so the
magit-rev-abbrev fallback always fires, eliminating the v4.3.3 speedup
that came from the one-shot git-log call.
The known reason for having duplicate commits across rebase todo lines
is that, when constructing commits to pass to git-log, a faulty
always-nil condition prevents the commit from being extracted from the
-C/-c options of merge lines. Once that condition is fixed, I haven't
found a case where two todo lines point to the same commit.
Revert the changes from 4fc60fdb and instead fix the merge condition,
adding an assertion on top so that someone will let us know if they
hit into a case where the resolved number of commits is fewer.
(Also, specify --no-walk=unsorted to ensure commits come back in the
order in which they were passed to git-log.)
Re: #5365
|
|
|
|
Closes #5365.
|
|
|
|
|
|
|
|
|
|
This counters Org commit 39264d3d41213085502dc0c2572f50855ea587a1.
|
|
oO
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Use one section per category, instead of one section per ref on the
line. This is the only place where we violated the rule that there
is only ever one section per line.
I always found it annoying that moving over these headers took more
key presses than expected when using `magit-next-section', and I
never developed an intuition for not using that command here, because
it so convincingly looks like using that is efficient enough.
An upcoming refactoring to section highlighting would break for these
sections, so let's address it now.
It is also simply unnecessary to use a section per branch. Nowadays
commands that act on the branch at point, need no section, a painted
ref will do. A small tweak to `magit-branch-at-point' will do.
|
|
Fixes a regression introduced in [1: 9a5228e2a9]. I found it rather
funny, and won't spoil the joke by explaining it, or maybe I am just
too lazy right now to write a professional commit message.
1: 2025-02-11 9a5228e2a952cd95c3585070865d1af158fc57ad
Call magit-insert-heading less often without arguments
|
|
I recommend using `magit-section-cycle-global' instead, but if one
happened to invoke the local variant at the end of the buffer (or
after the headers in the status buffer), then it was annoying that
this succeeded in expanding all sections, but then failed to hide
again on subsequent invocations with "Cannot hide root section".
|
|
Closes #5362.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
The order was reversed in the recent [1: 8e72767262].
1: 2025-04-15 8e7276726242ed7040a9c721a247a6d52397da95
Speed-up inserting rebase sequences
|
|
Closes #5361.
|
|
`forge-pullreq-state-set-merged' is going to use this.
|
|
|
|
|
|
|
|
Co-authored-by: Jonas Bernoulli <jonas@bernoul.li>
|
|
|
|
Closes #4057.
|
|
|
|
As for other ref lists.
|
|
We strongly discourage setting `magit-section-keep-region-overlay'
to t. If a user did that anyway that can lead to conflicts between
the involved faces. Before we tried to automatically avoid such a
potential conflict by only using the `:foreground' of the
`magit-*-heading-selection' faces, which is very confusing for users
who want to enable this and also use another face attribute.
|
|
Start doing so even after long-lines shortcuts kick in and even if the
new current section is the root section. In both cases sections might
be highlighted that should no longer be highlighted.
|
|
Replacing `magit-section--enable-long-lines-shortcuts'.
|
|
|
|
|
|
|
|
Remove that prefix when unshelving, but keep supporting unshelving
branches that were shelved without adding such a prefix.
|
|
|
