FetchContent_MakeAvailable fails if Git repository is deleted

I am using FetchContent like below

    GIT_REPOSITORY n     ssh://foo-url
    GIT_TAG              1.0.1
    GIT_SHALLOW          TRUE
    SOURCE_DIR           $ENV{HOME}/foo


If I explicitly delete foo (rm -rf ~/foo). And re-configure or delete cache and reconfigure, I get the following error…

[cmake] [ 11%] Performing update step for 'foo-populate'
[cmake] CMake Error at /home/vagrant/cmake_external_dependencies/foo-subbuild/foo-populate-prefix/tmp/foo-populate-gitupdate.cmake:25 (message):
[cmake]   Failed to get the hash for HEAD:
[cmake]   fatal: not a git repository (or any parent up to mount point /home)
[cmake]   Stopping at filesystem boundary (GIT_DISCOVERY_ACROSS_FILESYSTEM not set).

I’ve found my only option at this point is to delete the entire build directory (or specifically the foo-subbuild directory). Do I have any options here? Or is this the expected behavior? I would’ve perhaps thought that FetchContent would’ve been able to realize the repo no longer exists and re-clone it like it does on first configuration.

It sounds like there’s some missing sanity check here before trying to actually use the source directory. I wonder if the SOURCE_DIR combined with GIT_* is the cause (as I’ve not seen this with just GIT_* arguments).

Cc: @craig.scott

FetchContent and ExternalProject both use timestamps to work out whether some individual steps have been completed. In general, it isn’t safe to delete things as described in the original post. If you do want to delete parts, then you are also responsible for deleting any associated timestamps. Those are internal implementation details though, we don’t document how those timestamps are used. We do expose some degree of control over where those timestamps go (see the mention of STAMP_DIR in the ExternalProject docs), but not how they are used (and I don’t see that changing because we want the flexibility to change how they are used internally).

I’ve decided to trial CPM.cmake for the time being. Thank you for the response.