| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
Replace `magit-rev-hash' and some uses of `magit-commit-p',
preparing for `magit-commit-p' to return t instead of the oid.
|
|
Emacs 31.1 adds variable `lisp-indent-local-overrides'.
|
|
Emacs 31.1 adds variable `lisp-indent-local-overrides'.
|
|
|
|
This is useful when top-level forms are collapsed.
|
|
|
|
In [1: 4fed8d67a5] we accidentally started to include it by using
its first parent as the starting point.
1: 2025-03-31 4fed8d67a5a2edcf541aab6495542e23aff42f9b
magit-rebase-autosquash: With a prefix allow selecting beginning
|
|
Add a new argument EXACT for that purpose. If the start-point
is a root commit, then always rebase that too, using "--root",
and ignoring EXACT. Excluding that commit is undesirable even
for users who set `magit-rebase-interactive-include-selected'
to nil.
|
|
|
|
The space (if any) between the keyword and form is not stripped
when inserting the form into the autoloads file, which looks odd.
In Emacs the number of autoload cookies with and without such a
space, is almost the same, so that provides no guidance as to what
should be preferred. Go with what makes the aligner in me happy.
|
|
|
|
|
|
Stick to doing so using `magit--propertize-face' for now.
Stick to not doing it for strings inserted into minibuffers or
into transient menu buffers, or used in messages. (Except where we
already do.)
This needs more work (including design decisions). This commit just
fixes some broken cases.
|
|
If there is a single BODY form in the final clause, we can just
use that as the CONDITION instead (because the value of that is
returned if the BODY is empty).
I've been gravitating towards that style for a long time, but
because I realize that this is not without issue and that there
are certainly those that would find this practice questionable,
I refrained from updating existing code until now.
The main problem with dropping the `t' is that it is not always
immediately obvious if one is looking at
(cond
...
((foo bar)))
or
(cond
...
((foo) (bar)))
That's why I still use `t' when the single BODY form is too long
and/or complex, despite fitting on one line. In this case from
`magit-log-move-to-revision', for example, I was on the fence:
(cond
...
((apply #'magit-log-all-branches (magit-log-arguments))))
(It's worth noting that the same issue also occurs when reading
non-final-catch-all clauses.)
On the other hand, the single BODY form can also be complex
*enough* to allow using it as the CONDITION, without that being hard
to parse. E.g., when it spans multiple lines, and indentation keeps
increasing, and/or when BODY is a `let' from or similar.
Used like this, `cond' becomes more similar to `or' in certain
situations, but even then they still behave differently, consider:
(or (and CONDITION maybe-nil)
...)
vs
(cond (CONDITION maybe-nil)
...)
|
|
Anaphoric macros get a bad rep and while my own infatuation was somewhat
short lived, there are cases where I still find them useful, such as in
the case of
(and$ (function-with-a-name-that-makes-if-obvious-what-is-returned)
(function-with-a-name-that-makes-if-obvious-what-is-expected $))
Many of the cases where this commits starts using `and$', fall squarely
into that category. There are a few where I an on the fence. That's
because I've just invented this macro and need some practice to fully
develop my sense of when it is, and is not, appropriate to use this
macro.
|
|
Using the "other elements of VARLIST have access to SYMBOLs from
earlier elements" variant is IMHO _wrong_ when there are in fact
no other elements.
|
|
Cond-Let's `if-let', `if-let*', `when-let', `when-let*' and `and-let*'
implementations behave differently from the built-in implementations,
but because I have been careful not to depend on the idiosyncrasies,
switching over should be mostly safe.
Also add shorthands for the other `cond-let--...' macros. We will
start using those (and `cond-let' and `cond-let*') in later commits.
|
|
This was not done until now because doing so resulted in a warning
because the macro expansion did not actually leave any variables
unused. This was fixed in Emacs 30.1 and I've added a backport to
Transient, which this package can also take advantage of.
Without consistently using `_' one would always have to count parens
to be sure whether a member of the varlist does or does not bind a
variable. It is very easy to make mistake when writing or reading
such forms, if `_' is not consistently used in the non-binding cases.
|
|
This fixes the previous commit, [1: a6b9d55977].
1: 2025-07-29 a6b9d5597730d4e99f1f4eec04d7cef1bcda3424
Add to eieio--known-slot-names at run-time too
|
|
The libraries that make these additions are not the only ones that
use them before the respective classes are defined. When compiling
those other libraries we also don't want these warnings.
|
|
Almost always would it be better to use `match-string-no-properties'
instead of `match-string', but because the name of the former is
excruciatingly long for a function that one often wants to use in
tight spaces and because it usually "does not really matter", I
usually went for the latter.
The problem is, it does matter. For example, even strings that are
usually only used by code may end up obfuscating debug statements.
So let's start doing the right thing, even though there surely will
be people frowning at the use of a shorthand.
The fake ("match-string" "match-string") shorthand is necessary to
protect literal `match-string' and `match-string-no-properties' from
being corrupted by interpreted as shorthand for the non-existent
`match-stringing' and `match-string-no-propertiesing'.
Unfortunately the shorthands have to be specified in each library
individually. Using "dir-locals.el" only works if the libraries
are compiled. At least this additional noise is neatly tucked away
at the end of the files.
It might turn out that out of the more than two hundred instances
where this replaces `match-string' with `match-string-no-properties'
we should have stuck with the former in an instance or two. That's
the price of progress and can be fixed once such regressions are
reported.
|
|
Previously, if `git-rebase-show-instructions' was non-nil, it was
possible that a line containing usage information was mistaken for
a rebase action.
Alternatively we could use `with-editor-pre-finish-hook' to flush the
usage information after the user has seen them, just like we flush them
earlier in `git-rebase-mode', iff `git-rebase-show-instructions' is nil.
|
|
When rebase stops at the last commit, then the list of commits yet
to be rebases is (obviously) empty.
Don't call "git log --no-walk --format=%h [<commit>...]" in that
case, because if that is called without any revision arguments,
it shows information for HEAD. That resulted in an error because
we later assert that the commit and abbreviation lists have the
same length.
Re #5365.
|
|
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.
|
|
|
|
The order was reversed in the recent [1: 8e72767262].
1: 2025-04-15 8e7276726242ed7040a9c721a247a6d52397da95
Speed-up inserting rebase sequences
|
|
|
|
|
|
The two backends are now named "merge" and "apply"; no longer
"interactive" and "am", see Git commit [1: 10cdb9f38a].
1: 2020-02-16 10cdb9f38adaa16aad64403bc931405564523985
rebase: rename the two primary rebase backends
|
|
|
|
|
|
|
|
|
|
|
|
|
|
In two cases use lambda, not ##.
|
|
|
|
In one case use lambda and in another pcase-lambda, not ##.
|
|
|
|
In three cases use lambda, not ##.
|
|
|
|
|
|
But "demote" it a bit, in all menus, by placing it after `--gpg-sign'
and putging it on level 6.
Closes #5297.
|
|
|
|
That was released five years ago.
|
