The upgrade process leaves a left over ref:
```
$ git branch
..
_upgrade_HEAD
..
```
This commit deletes that.
Signed-off-by: Rudi Grinberg <me@rgrinberg.com>
`doom-cli-upgrade` calls `git fetch` to fetch remote branch and tags and
check output code of this command to complain when it failed.
It fails when remote server isn't available that is good.
But it also fails when it can't to fast-forward a branch that will be
used to upgrade doom-emacs.
The last case created a loop and the only way to broke this loop is
remote a branch that should be used for upgrade.
Unfortunately user has no idea about branch name and can't do anything,
just enjoy crash with `Failed to fetch from upstream` message.
This commit added `--force` flag to `git fetch` that forces it to
overwrite branch that is used to upgrade that prevent such loop.
It also fixed https://github.com/hlissner/doom-emacs/issues/4346
Previously, `doom upgrade` would emit:
```
New revision: fatal: amb (fatal: ambiguous argument '_upgrade/HEAD': unknown revision or path not in the working tree.
Use '--' to separate paths from revisions, like this:
```
It appears it's not possible to remote revisions with
`<remote>/<revision>`. Instead, we fetch the upgrade remote into a named
revision and then use it.
Signed-off-by: Rudi Grinberg <me@rgrinberg.com>
When compiling standalone files such as `init.el`, instead of saying
that it belongs to module `nil nil`, say that these files are
standalone.
Signed-off-by: Rudi Grinberg <me@rgrinberg.com>
Renamed `comp-deferred-compilation-black-list` to
`comp-deferred-compilation-deny-list`.
Removed the `late` load flag which is no longer required.
Added a check against the deny list when compiling all Elisp on the
load-path, so we don't inadvertently compile something we shouldn't.
Added compatibility shims to ease transition from older builds of
native-comp.
This is a workaround for 'doom build' hanging on native-comp Emacs when
run with an empty cache. We're effectively automating the process of
killing 'doom build' and trying again.
Add an extra pass to `doom build` to queue native compilation of all
packages on `load-path`. This ensures that all core and site Elisp
packages are actually native-compiled, even on "fast boot" builds.
Add `.local/autolads.el` to the blacklist as native-compiling this file
succeeds, but prevents emacs from starting up.
Revise the evil-collection-vterm blacklist entry to use a more efficient
regex.
Fix a bug where an updated .error file wasn't always written, causing
spurious rebuilds.
The latest straight.el adds `:no-native-compile` packages to the
compilation blacklist. We export the build-time blacklist via autoloads
so that it works as expected to prevent native compilation at runtime.
Still a long way to go, but this introduces a few niceties for
debugging CLI failures:
+ The (extended) output of the last bin/doom command is now logged to
~/.emacs.d/.local/doom.log
+ If an error occurs, short backtraces are displayed whether or not you
have debug mode on. The full backtrace is written to
~/.emacs.d/.local/doom.error.log.
+ bin/doom now aborts with a warning if:
- The script itself or its parent directory is a symlink. It's fine if
~/.emacs.d is symlinked though.
- Running bin/doom as root when your DOOMDIR isn't in /root/.
- If you're sporting Emacs 26.1 (now handled in the elisp side rather
than the /bin/sh shebang preamble).
+ If a 'doom sync' was aborted prematurely, you'll be warned that Doom
was left in an inconsistent state and that you must run `doom sync`
again.
May address #3746
