Open alex-ilin opened 4 years ago
I don't use submodules myself. So I can't judge whether that change would be wanted by all submodules users. Do you have an opinion about that?
Would setting git config submodule.recurse true
have the effect that you want, or would that have unwanted side-effects?
I have the feeling that proper support for submodules would require some other changes in git-test
, for example in refresh_index
, unstaged_changes
, and uncommitted_changes
, where we explicitly pass --ignore-submodules
to git commands.
I use submodules a lot to track dependencies between projects. I have a Library project and multiple Application projects that use functions and features provided by the Library. Each Application has its own submodule pointer into the Library repo, which fixes and documents the required version of the Library for that project.
Often new features in an Application need to be developed with corresponding additions in the Library, and sometimes fixing a bug in an Application involves fixing the Library. In these cases updating the Library pointer is the necessary part of the commit in the Application, since otherwise anyone else making a checkout of the Application won't get the correct version of the Library, and in the best case the project compilation will fail (in the worst case they'll build an Application with incorrect behavior, or with unfixed bugs).
In fact, the main reason I found, downloaded and started using git-test
was to make sure that after a big rebase, which required rebasing both in an Application and in the Library, the branches were properly stitched together. Meaning, the new submodule pointers in the Application are referencing the correct new commits in the Library. In my case it was only the compilability test: I needed to make sure that each new commit of the Application can be built against the Library commit that it references, so that there were no missing or skipped pointer updates, and that the commits in the Library didn't get significantly reordered to break compilation of the superproject.
I use Git submodules for dependency tracking for many years now (and before Git I used the svn:externals
property), and I strongly feel that a fresh checkout for testing purposes needs to update all submodules recursively, otherwise we don't know what mixture of states we are going to be testing. It may make sense to put some submodules out of the expected state for a manual test now and then, but not for such an automation as git-test
provides.
I couldn't find any specific documentation about the submodule.recurse
configuration option but if it is like passing --recurse-submodules
to git checkout
, and if the user follows (like I did) the recommended step of creating the worktree for testing, then it would still lack the --init
option. The git checkout --recurse-submodules
only updates the existing submodules, but doesn't initialize them if they are missing, which they would be in a fresh worktree.
I didn't look into the source, but maybe all you need to do about those --ignore-submodules
is to just remove them. Alternatively, you could support the --ignore-submodules
option for git-test
itself, and pass it through, if supplied, to those functions.
@alex-ilin Have you tested using GIT_TEST_PREVIOUS_CHECKED_OUT_COMMIT
to update submodules?
@hlovdal I have not.
To make
git-test
usable in my repositories, I have to addgit submodule update --init --force --recursive
to the top of my build script. It seems that this should be done bygit-test
itself as part of checking out the next commit.