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.