| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
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>
|
|
|
|
|
|
|
|
Use the term "dissolve" because that makes it clear that the branch that
is being merged is also deleted afterwards. Also change the key binding
in the `magit-merge' menu, to keep it mnemonic. At least the latter was
planned since [1: 4c096921fd]. Do not define `magit-merge-into' as an
obsolete alias, since that would prolong the period during which some
users would by take by surprise.
Re #4386.
1: 2021-07-01 4c096921fda97ebdff656a35a257910fca9e5aad
magit-merge: Change magit-merge-into's description
|
|
|
|
|
|
Closes #5308.
|
|
|
|
|
