mhagger / git-test

Run automated tests against a range of Git commits and keep track of the results
GNU General Public License v2.0
68 stars 15 forks source link

Bug: submodules are not updated before test runs #13

Open alex-ilin opened 4 years ago

alex-ilin commented 4 years ago

To make git-test usable in my repositories, I have to add git submodule update --init --force --recursive to the top of my build script. It seems that this should be done by git-test itself as part of checking out the next commit.

mhagger commented 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.

alex-ilin commented 4 years ago

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.

hlovdal commented 1 year ago

@alex-ilin Have you tested using GIT_TEST_PREVIOUS_CHECKED_OUT_COMMIT to update submodules?

alex-ilin commented 1 year ago

@hlovdal I have not.