On 21 Sep 2026 13:20, Alexander Grund via Boost wrote:
Am 21.09.26 um 02:06 schrieb Andrey Semashev via Boost:
My Boost.Filesystem CI fails to checkout Boost.Container as a dependency on a few runners:
Installing: core, exception, container, thread, iterator, bind, detail, timer, system, assert, smart_ptr, foreach, container_hash, test, range, config, throw_exception, utility fatal: reference is not a tree: fb208a12155fb57e5dd44e6ec22fae413f6a2966 Unable to checkout 'fb208a12155fb57e5dd44e6ec22fae413f6a2966' in submodule path 'libs/container' The root project points to Boost.Container commit fda4e33 since 3hrs ago. Which does exist. So restarting your jobs (or pushing another commit) should work now.
Yes, the checkout seems to be working now.
https://github.com/boostorg/filesystem/actions/runs/35538790711/ job/106170376917
This is happening consistently on Ubuntu 16.04 runners but not others for some reason. I can't see the commit fb208a12155fb57e5dd44e6ec22fae413f6a2966 in my local develop, but there seem to have been a forced push. I'm guessing the commit is referenced by the superproject, and it's not getting updated? IIRC the update happens periodically only although usually in just a couple hour intervals. Also, I noticed Boost.Container git repository is in a permanently modified state:
modified: include/boost/container/allocator.hpp modified: include/boost/container/node_allocator.hpp
These files contain CRLF that are automatically converted to LF by git, making these files modified:
I guess your local git config (especially `core.auocrlf`) changed at some point. Git can be told to checkout in a specific style or use what is in the repo.
My core.auocrlf == input, and it has been this way since forever. I'm on Linux, so the setting is the way it is intended. I think, someone committed CRLF line endings in git, i.e. someone had core.auocrlf == false at that point, which is not recommended. So I'm asking that someone to fix the line endings in git and maybe update his git configuration.
If you don't have local modifications that you want to keep in that subfolder, then e.g. `git co master; git co develop` might be enough if `git co .` doesn't already resolve the diff
No, that doesn't work. `git checkout develop`, `git reset --hard` or `git stash` all leave the tree in modified state. E.g. `git checkout master` in that state fails with an error about local changes. Only `git checkout master --force` works, but I would rather not have to do that.
This makes working with the repository a pain. Could this be fixed, please?
See above: You can fix that yourself as it is an "issue" in your local checkout only.
No, I don't think so, as I explained above.