Change:
cd "$repo" # Remove files that contain timestamps or otherwise have non-deterministic # properties. <del> rm -rf .git/logs/ .git/hooks/ .git/index .git/FETCH_HEAD .git/ORIG_HEAD  .git/refs/remotes/origin/HEAD .git/config </del> <ins> if [ -f .git ]; then local dotgit_content=$(<.git) local dotgit_dir="${dotgit_content#gitdir: }" else local dotgit_dir=".git" fi pushd "$dotgit_dir" rm -rf logs/ hooks/ index FETCH_HEAD ORIG_HEAD refs/remotes/origin/HEAD config popd </ins> # Remove all remote branches. git branch -r | while read -r branch; do clean_git branch -rD "$branch"

Discussion:
fails when using and with repositories that contain submodules. A checked-out repository that contains modules will have files pointing to . git uses files to "link" submodules gitdirs to the root path. I'm not sure if this is new git behavior and thus it broke . See below in the reproduction section. () tries to list directories and get their parent paths with , but finds files and fails. , it fails silently and won't return an error to the parent shell (and won't trigger ), so in these cases is called and fails with "not a git repository" errors. A possible fix is to use to filter directories. I believe this option/value is portable. This will only give directory paths and avoid the very subtly error. Checked-out repository with submodule: Emulating the branch: Expected to correctly fetch a repository with submodules and leave directories intact when is true. I'm not sure who are owners. I'm tagging the last 3 who touched :
Could be triggered by , if you revert it does it work?
I can't test right now, but from a cursory reading, I think it indeed does, because it changed behavior from A) manually getting all submodules urls and manually cloning the repos, which will result in directories, to B) , which generates files, like I described above.
Sounds good, can you make a PR? This also means that probably the hash is now different.
I tried adding to both of these instances: But I ended up with a non-deterministic hash for some reason - every run would result in a different hash. Reverting does fix the issue though. should we revert that commit until this is sorted out?
I can help fix it if you find a good example within nixpkgs repo to test with.
there are only a few cases where both flags are used in nixpkgs. At least from searching with . Only one I could find was : But for some reason it doesn't reproduce this issue. I'm not sure we currently have a derivation in nixpkgs that reproduces this. I've been able to reproduce this easily with a derivation which uses this :
I can reproduce this issue in the following case:
Could you test
I tested with and it worked. The repository in question and even , which triggers the bug in .

I wasn't sure what's the best practice when dealing with projects relying on git to build correctly and since it's hardcoded in that project's build script with no trivial solution (like setting an env var or passing a CLI flag), I was actually trying to build it as-is. Now that I see landed, my question was answered: just patch it out. Anyway, the bug still exists and it seems works for this specific repository, even with all the shenanigans at build time. Thanks