| Age | Commit message (Collapse) | Author |
|---|
|
|
|
Closes #5283.
|
|
The description of `magit-rebase-subset' did not mention the underlying
Git command it runs, nor does it explain that HEAD must already be at
the desired upper bound before invoking it.
This is a discoverability problem for users coming from the Git CLI.
"git rebase --onto NEWBASE START END" is a well-known pattern, but
there was no hint in the manual that this is its Magit equivalent.
|
|
|
|
|
|
|
|
magit-stage-buffer-file and magit-unstage-buffer-file were renamed to
magit-file-stage and magit-file-unstage in bf920b7ff (2025-03-31).
|
|
magit-stage-file and magit-unstage-file were renamed to
magit-stage-files and magit-unstage-files in 993cdf0aa (2025-03-31).
|
|
Closes #5523.
|
|
|
|
This section inserter is handy, and has existed since 2.7.0 /
82bfdd46295c5d6fa5d1a26a5058994e5b4f7c56... but appears to not yet be
documented.
This documentation is modeled in the style of
`magit-sparse-checkout-insert-header', where it is mentioned in the
docs for the relevant commands rather than the docs of `magit-status',
since most people who wish see a list of worktrees are likely using
`magit-worktree' / reading its documentation.
|
|
|
|
Replace `magit-section-visibility-indicator'.
Closes #5463.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
I strongly recommend you don't change the value of this option.
See the information I have added to the manual.
Closes #5421.
|
|
|
|
In [1: 9b4ce73f74] we stopped respecting the value of this variable.
1: 2025-07-30 9b4ce73f74a3a9dda769ade9fa52b59214f085dc
magit-diff-on-removed-line-p: New function
|
|
Changing its value is discouraged, so move it out of sight.
|
|
|
|
|
|
[1: 6aec967ee4] moved Ido support to the new `magit-ido' package.
1: 2025-03-30 6aec967ee4af617ddae577153208bd8a8bb011f0
Move Ido kludges to a new package magit-ido
|
|
|
|
Closes #5429.
|
|
|
|
|
|
|
|
Previously "q" in a blob buffer unconditionally killed it. I have
a personal command that displays the current buffer in a new frame
(while still displaying it in the old window/frame), which I often
follow up by quitting the current buffer in the old window, which
then ends up killing the buffer "in both frames".
On the other hand, when time traveling, it is useful if "q" cleans
up completely, else we would end up with many blob buffers, which
are no longer of interest.
Determining whether to kill or only bury the current buffer based on
whether it is displayed in a second window, covers both use-cases.
Other users might find different behaviors useful, so implement and
mention some alternatives.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Closes #5394.
|
|
|
|
The old variant broke with [1: 95ee9d8c51], which cannot be fixed simply
be reverting that commit, because it was in preparation of subsequent
changes, which heavily refactored section highlighting making it both
simpler and more generic, and also to improve performance. Delayed hunk
refinement conflicts with the former, and due to the latter it might not
be necessary anymore.
This commit does not fully restore the old behavior. Previously
delayed refinement meant that only the current hunk was ever refined;
when another section became current, the refinement of the previously
current section was removed again. Now, once a hunk has been refined,
it remains refined, until the buffer is refreshed.
The reason any form of delayed hunk refinement was implemented in the
first place, was to avoid the upfront cost of completely refining a
large diff. I never considered this a desirable feature; just a kludge
that was sadly necessary for performance reasons. IMO the new behavior
is an improvement; though always refining all hunks is of course even
better, unless it is too slow of course.
Closes #5385.
1: 2025-04-26 95ee9d8c5102bc5619f0e2c6d50104cae17b2009
magit-diff-paint-hunk: Only refine if actually painting
|
|
|
|
|
|
|
|
|
|
Co-authored-by: Jonas Bernoulli <jonas@bernoul.li>
|
|
|
