| Age | Commit message (Collapse) | Author |
|---|
|
|
|
Emacs 31.1 adds variable `lisp-indent-local-overrides'.
|
|
|
|
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.
|
|
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)
...)
|
|
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.
|
|
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.
|
|
|
|
git pull and git fetch allow the "--force" switch to force update local
branches. From man git-fetch(1):
-f, --force
When git fetch is used with <src>:<dst> refspec it may refuse
to update the local branch as discussed in the <refspec> part
below. This option overrides that check.
Add that option to `magit-pull' and `magit-fetch'. Use "-F" as the
suffix to be consistent with `magit-push'.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
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.
|
|
|
|
|
|
|
|
|
|
|
|
Closes #4031.
|
|
|
|
The option `magit-remote-set-if-missing' was remove in
07ca042b612150b7e6b4d4fb0078687e1e463759 but the manual
continued to refer to it. Fix that.
Also use a more uniform description to explain when the
remote is read from the user.
Closes #4029.
|
|
|
|
* Continue to use only `face' for strings that will be used by
Transient, and for `read-char-choice' prompts.
* Also leave `git-commit-propertize-diff' along because it already
does face/font-lock-face conversion at runtime.
* Otherwise when returning a string use `face' AND `font-lock-face'.
This is done using the new functions `magit--propertize-face' and
`magit--put-face'.
|
|
|
|
... instead of `magit-split-branch-name'. We can use the former
because we know that SOURCE is an existing named remote-tracking
branch. (Except when this command is called non-interactively,
but in that case the byte-compiler warns about it only being
intended for interactive use.)
Remove `magit-git-pull' and do the work directly in
`magit-pull-branch' because that was the last remaining caller.
|
|
|
|
|
|
The commands that previously respected this variable now always let
the user set the upstream/push-remote, provided HEAD is not detached.
It is no longer possible to disable this feature.
This variable was also used to configure whether "remote.pushDefault"
or "branch.<name>.pushRemote" is set by the push-remote commands.
Add a new option `magit-prefer-push-default' for that purpose.
|
|
|
|
Closes #3758.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
