This was the last failure. Unsure why this doesn't occur with other submodules.
https://github.com/DFHack/dfhack/runs/3307299302?check_suite_focus=true
```
+ git checkout dfhack
Previous HEAD position was 19b52ca 0.15.0 release
Switched to branch 'dfhack'
+ git pull --ff-only
There is no tracking information for the current branch.
Please specify which branch you want to merge with.
See git-pull(1) for details.
git pull <remote> <branch>
If you wish to set tracking information for this branch you can do so with:
git branch --set-upstream-to=origin/<branch> dfhack
```
Shallow clones cause issues with `git push --recurse-submodules=check|on-demand`
such as in https://github.com/DFHack/dfhack/runs/3307192897?check_suite_focus=true:
```
The following submodule paths contain changes that can
not be found on any remote:
depends/luacov
Please try
git push --recurse-submodules=on-demand
or cd to the path and use
git push
to push them to a remote.
```
(in this case, the changes *are* on the remote, and on-demand doesn't help)
Our submodules also aren't currently very large on disk even with full clones -
libexpat is the largest:
616K .git/modules/depends/clsocket
744K .git/modules/depends/luacov
924K .git/modules/depends/xlsxio
1.8M .git/modules/depends/libzip
3.7M .git/modules/depends/jsoncpp
8.2M .git/modules/depends/libexpat
If a shallow clone of submodules is desired, `git clone --shallow-submodules` is
still an option.
this fixes the issue where the alt modstate was getting stuck on systems
that don't send standard keyup events after alt-tab. for example, in KDE
Plasma (on Gentoo, at least), the keyup event when alt is released after
alt-tab contains an incorrect keycode (NUMLOCK instead of L_ALT), which
was preventing us from correctly clearing the alt modstate.
we normally take care of any ramp tops above the channeled tile when we dig the ramp below the channeled
tile, but that logic might not run if we channel down into empty space
(or undiggable tiles)
DFHack-Urist via GitHub Actions
lethosor
myk002