Hi, 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' Error: The command 'git submodule -q update --init libs/core libs/exception libs/container libs/thread libs/iterator libs/bind libs/detail libs/timer libs/system libs/assert libs/smart_ptr libs/foreach libs/container_hash libs/test libs/range libs/config libs/throw_exception libs/utility' failed with exit code 256 Error: Process completed with exit code 1. https://github.com/boostorg/filesystem/actions/runs/35538790711/job/10617037... 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? 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: $ git diff warning: in the working copy of 'include/boost/container/allocator.hpp', CRLF will be replaced by LF the next time Git touches it warning: in the working copy of 'include/boost/container/node_allocator.hpp', CRLF will be replaced by LF the next time Git touches it diff --git a/include/boost/container/allocator.hpp b/include/boost/container/allocator.hpp index 27fe145..6d7c183 100644 --- a/include/boost/container/allocator.hpp +++ b/include/boost/container/allocator.hpp @@ -288,7 +288,7 @@ class allocator void allocate_many(size_type elem_size, std::size_t n_elements, multiallocation_chain &chain) { BOOST_CONTAINER_STATIC_ASSERT(( Version > 1 )); - dlmalloc::memchain ch; + dlmalloc::memchain ch; if(!dlmalloc_heap().multialloc_nodes(n_elements, elem_size*sizeof(T), dlmalloc::default_contiguous, &ch)){ boost::container::throw_bad_alloc(); } @@ -309,7 +309,7 @@ class allocator void allocate_many(const size_type *elem_sizes, size_type n_elements, multiallocation_chain &chain) { BOOST_CONTAINER_STATIC_ASSERT(( Version > 1 )); - dlmalloc::memchain ch; + dlmalloc::memchain ch; if(!dlmalloc_heap().multialloc_arrays(n_elements, elem_sizes, sizeof(T), dlmalloc::default_contiguous, &ch)){ boost::container::throw_bad_alloc(); } diff --git a/include/boost/container/node_allocator.hpp b/include/boost/container/node_allocator.hpp index 9256946..0f6804c 100644 --- a/include/boost/container/node_allocator.hpp +++ b/include/boost/container/node_allocator.hpp @@ -271,7 +271,7 @@ class node_allocator void allocate_many(size_type elem_size, std::size_t n_elements, multiallocation_chain &chain) { BOOST_CONTAINER_STATIC_ASSERT(( Version > 1 )); - dlmalloc::memchain ch; + dlmalloc::memchain ch; if(BOOST_UNLIKELY(!dlmalloc_heap().multialloc_nodes(n_elements, elem_size*sizeof(T), dlmalloc::default_contiguous, &ch))){ boost::container::throw_bad_alloc(); } @@ -286,7 +286,7 @@ class node_allocator void allocate_many(const size_type *elem_sizes, size_type n_elements, multiallocation_chain &chain) { BOOST_CONTAINER_STATIC_ASSERT(( Version > 1 )); - dlmalloc::memchain ch; + dlmalloc::memchain ch; dlmalloc_heap().multialloc_arrays(n_elements, elem_sizes, sizeof(T), dlmalloc::default_contiguous, &ch); if(BOOST_UNLIKELY(ch.empty())){ boost::container::throw_bad_alloc(); This makes working with the repository a pain. Could this be fixed, please?
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. https://github.com/boostorg/filesystem/actions/runs/35538790711/job/10617037...
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. 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
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.
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.
On 21 Sep 2026 15:43, Andrey Semashev wrote:
On 21 Sep 2026 13:20, Alexander Grund via Boost wrote:
Am 21.09.26 um 02:06 schrieb Andrey Semashev via Boost:
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.
*autocrlf. The typo is in the email only, the config is correct.
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.
Am 21.09.26 um 14:43 schrieb Andrey Semashev via Boost:
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. Looks like you are right. After rereading the docs it seems to be caused by `.gitattributes` being in some non-conformant style, likely after SVN migration.
That was supposed to ensure LF is always used in the repo commits, but didn't work. I opened https://github.com/boostorg/container/pull/348 to fix the gitattributes and existing mistakes in the files you've noticed. I encourage everyone to do the same to the repositories they maintain. I left a 1/3-liner that I used.
On 21 Sep 2026 16:27, Alexander Grund via Boost wrote:
Am 21.09.26 um 14:43 schrieb Andrey Semashev via Boost:
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. Looks like you are right. After rereading the docs it seems to be caused by `.gitattributes` being in some non-conformant style, likely after SVN migration.
That was supposed to ensure LF is always used in the repo commits, but didn't work.
I opened https://github.com/boostorg/container/pull/348 to fix the gitattributes and existing mistakes in the files you've noticed.
I encourage everyone to do the same to the repositories they maintain. I left a 1/3-liner that I used.
Thanks. I created a PR fixing the line endings but yours also updates .gitattributes, so I've closed mine.
El 21/09/2026 a las 15:55, Andrey Semashev via Boost escribió:
On 21 Sep 2026 16:27, Alexander Grund via Boost wrote:
Am 21.09.26 um 14:43 schrieb Andrey Semashev via Boost:
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. Looks like you are right. After rereading the docs it seems to be caused by `.gitattributes` being in some non-conformant style, likely after SVN migration.
That was supposed to ensure LF is always used in the repo commits, but didn't work.
I opened https://github.com/boostorg/container/pull/348 to fix the gitattributes and existing mistakes in the files you've noticed.
I encourage everyone to do the same to the repositories they maintain. I left a 1/3-liner that I used.
Thanks. I created a PR fixing the line endings but yours also updates .gitattributes, so I've closed mine.
Hi, Thanks for your reports, and sorry for the inconveniences. I realized that Container repository had a 100 MB folder with Cursor garbage under the experimental folder and decided to rewrite the history to avoid that mistake for users. Somehow the superproject commit bot needs some time (I've not seen any manual commit in the superproject repo) to recover from this trauma (I guess the old commit was orphan) and pick the latest commit from develop again. Thanks for the PRs, I'll check it ASAP and review my other libraries. Best, Ion
participants (3)
-
Alexander Grund -
Andrey Semashev -
Ion Gaztañaga