summaryrefslogtreecommitdiff
path: root/t/lib-submodule-update.sh
AgeCommit message (Collapse)AuthorFilesLines
2019-04-01t/lib-submodule-update: use appropriate length constantLibravatar brian m. carlson1-1/+2
Instead of using a specific invalid hard-coded object ID, produce one of the appropriate length by using test_oid. Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-12-26submodule deinit: unset core.worktreeLibravatar Stefan Beller1-1/+1
When a submodule is deinit'd, the working tree is gone, so the setting of core.worktree is bogus. Unset it. As we covered the only other case in which a submodule loses its working tree in the earlier step (i.e. switching branches of top-level project to move to a commit that did not have the submodule), this makes the code always maintain core.worktree correctly unset when there is no working tree for a submodule. This re-introduces 984cd77ddb (submodule deinit: unset core.worktree, 2018-06-18), which was reverted as part of f178c13fda (Revert "Merge branch 'sb/submodule-core-worktree'", 2018-09-07) The whole series was reverted as the offending commit e98317508c (submodule: ensure core.worktree is set after update, 2018-06-18) was relied on by other commits such as 984cd77ddb. Keep the offending commit reverted, but its functionality came back via 4d6d6ef1fc (Merge branch 'sb/submodule-update-in-c', 2018-09-17), such that we can reintroduce 984cd77ddb now. Signed-off-by: Stefan Beller <sbeller@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-12-26submodule: unset core.worktree if no working tree is presentLibravatar Stefan Beller1-1/+2
When a submodules work tree is removed, we should unset its core.worktree setting as the worktree is no longer present. This is not just in line with the conceptual view of submodules, but it fixes an inconvenience for looking at submodules that are not checked out: git clone --recurse-submodules git://github.com/git/git && cd git && git checkout --recurse-submodules v2.13.0 git -C .git/modules/sha1collisiondetection log fatal: cannot chdir to '../../../sha1collisiondetection': \ No such file or directory With this patch applied, the final call to git log works instead of dying in its setup, as the checkout will unset the core.worktree setting such that following log will be run in a bare repository. This patch covers all commands that are in the unpack machinery, i.e. checkout, read-tree, reset. A follow up patch will address "git submodule deinit", which will also make use of the new function submodule_unset_core_worktree(), which is why we expose it in this patch. This patch was authored as 4fa4f90ccd (submodule: unset core.worktree if no working tree is present, 2018-06-12), which was reverted as part of f178c13fda (Revert "Merge branch 'sb/submodule-core-worktree'", 2018-09-07). The revert was needed as the nearby commit e98317508c (submodule: ensure core.worktree is set after update, 2018-06-18) is faulty and at the time of 7e25437d35 (Merge branch 'sb/submodule-core-worktree', 2018-07-18) we could not revert the faulty commit only, as they were depending on each other: If core.worktree is unset, we have to have ways to ensure that it is set again once the working tree reappears again. Now that 4d6d6ef1fc (Merge branch 'sb/submodule-update-in-c', 2018-09-17), specifically 74d4731da1 (submodule--helper: replace connect-gitdir-workingtree by ensure-core-worktree, 2018-08-13) is present, we already check and ensure core.worktree is set when populating a new work tree, such that we can re-introduce the commits that unset core.worktree when removing the worktree. Signed-off-by: Stefan Beller <sbeller@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> Signed-off-by: Stefan Beller <sbeller@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-09-07Revert "Merge branch 'sb/submodule-core-worktree'"Libravatar Jonathan Nieder1-3/+2
This reverts commit 7e25437d35a70791b345872af202eabfb3e1a8bc, reversing changes made to 00624d608cc69bd62801c93e74d1ea7a7ddd6598. v2.19.0-rc0~165^2~1 (submodule: ensure core.worktree is set after update, 2018-06-18) assumes an "absorbed" submodule layout, where the submodule's Git directory is in the superproject's .git/modules/ directory and .git in the submodule worktree is a .git file pointing there. In particular, it uses $GIT_DIR/modules/$name to find the submodule to find out whether it already has core.worktree set, and it uses connect_work_tree_and_git_dir if not, resulting in fatal: could not open sub/.git for writing The context behind that patch: v2.19.0-rc0~165^2~2 (submodule: unset core.worktree if no working tree is present, 2018-06-12) unsets core.worktree when running commands like "git checkout --recurse-submodules" to switch to a branch without the submodule. If a user then uses "git checkout --no-recurse-submodules" to switch back to a branch with the submodule and runs "git submodule update", this patch is needed to ensure that commands using the submodule directly are aware of the path to the worktree. It is late in the release cycle, so revert the whole 3-patch series. We can try again later for 2.20. Reported-by: Allan Sandfeld Jensen <allan.jensen@qt.io> Helped-by: Stefan Beller <sbeller@google.com> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-08-02Merge branch 'es/test-fixes'Libravatar Junio C Hamano1-3/+2
Test clean-up and corrections. * es/test-fixes: (26 commits) t5608: fix broken &&-chain t9119: fix broken &&-chains t9000-t9999: fix broken &&-chains t7000-t7999: fix broken &&-chains t6000-t6999: fix broken &&-chains t5000-t5999: fix broken &&-chains t4000-t4999: fix broken &&-chains t3030: fix broken &&-chains t3000-t3999: fix broken &&-chains t2000-t2999: fix broken &&-chains t1000-t1999: fix broken &&-chains t0000-t0999: fix broken &&-chains t9814: simplify convoluted check that command correctly errors out t9001: fix broken "invoke hook" test t7810: use test_expect_code() instead of hand-rolled comparison t7400: fix broken "submodule add/reconfigure --force" test t7201: drop pointless "exit 0" at end of subshell t6036: fix broken "merge fails but has appropriate contents" tests t5505: modernize and simplify hard-to-digest test t5406: use write_script() instead of birthing shell script manually ...
2018-07-24Merge branch 'sb/submodule-move-head-error-msg'Libravatar Junio C Hamano1-1/+2
"git checkout --recurse-submodules another-branch" did not report in which submodule it failed to update the working tree, which resulted in an unhelpful error message. * sb/submodule-move-head-error-msg: submodule.c: report the submodule that an error occurs in
2018-07-03t/lib-submodule-update: fix "absorbing" testLibravatar Eric Sunshine1-3/+2
This test has been dysfunctional since it was added by 259f3ee296 (lib-submodule-update.sh: define tests for recursing into submodules, 2017-03-14), however, the problem went unnoticed due to a broken &&-chain. The test wants to verify that replacing a submodule containing a .git directory will absorb the .git directory into the .git/modules/ of the superproject, and then replace the working tree content appropriate to the superproject. It is, therefore, incorrect to check if the submodule content still exists since the submodule will have been replaced by the content of the superproject. Fix this by removing the submodule content check, which also happens to be the line that broke the &&-chain. While at it, fix broken &&-chains in a couple neighboring tests. Helped-by: Stefan Beller <sbeller@google.com> Signed-off-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Stefan Beller <sbeller@google.com> Signed-off-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-06-25submodule.c: report the submodule that an error occurs inLibravatar Stefan Beller1-1/+2
When an error occurs in updating the working tree of a submodule in submodule_move_head, tell the user which submodule the error occurred in. The call to read-tree contains a super-prefix, such that the read-tree will correctly report any path related issues, but some error messages do not contain a path, for example: ~/gerrit$ git checkout --recurse-submodules origin/master ~/gerrit$ fatal: failed to unpack tree object 07672f31880ba80300b38492df9d0acfcd6ee00a Give the hint which submodule has a problem. Signed-off-by: Stefan Beller <sbeller@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-06-19submodule deinit: unset core.worktreeLibravatar Stefan Beller1-1/+1
When a submodule is deinit'd, the working tree is gone, so the setting of core.worktree is bogus. Unset it. Signed-off-by: Stefan Beller <sbeller@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-06-14submodule: unset core.worktree if no working tree is presentLibravatar Stefan Beller1-1/+2
When a submodules work tree is removed, we should unset its core.worktree setting as the worktree is no longer present. This is not just in line with the conceptual view of submodules, but it fixes an inconvenience for looking at submodules that are not checked out: git clone --recurse-submodules git://github.com/git/git && cd git && git checkout --recurse-submodules v2.13.0 git -C .git/modules/sha1collisiondetection log fatal: cannot chdir to '../../../sha1collisiondetection': \ No such file or directory With this patch applied, the final call to git log works instead of dying in its setup, as the checkout will unset the core.worktree setting such that following log will be run in a bare repository. This patch covers all commands that are in the unpack machinery, i.e. checkout, read-tree, reset. A follow up patch will address "git submodule deinit", which will also make use of the new function submodule_unset_core_worktree(), which is why we expose it in this patch. Signed-off-by: Stefan Beller <sbeller@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-01-05submodule: submodule_move_head omits old argument in forced caseLibravatar Stefan Beller1-0/+14
When using hard reset or forced checkout with the option to recurse into submodules, the submodules need to be reset, too. It turns out that we need to omit the duplicate old argument to read-tree in all forced cases to omit the 2 way merge and use the more assertive behavior of reading the specific new tree into the index and updating the working tree. Signed-off-by: Stefan Beller <sbeller@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-01-05t/lib-submodule-update.sh: fix test ignoring ignored files in submodulesLibravatar Stefan Beller1-0/+1
It turns out that the test replacing a submodule with a file with the submodule containing an ignored file is incorrectly titled, because the test put the file in place, but never ignored that file. When having an untracked file Instead of an ignored file in the submodule, git should refuse to remove the submodule, but that is a bug in the implementation of recursing into submodules, such that the test just passed, removing the untracked file. Fix the test first; in a later patch we'll fix gits behavior, that will make sure untracked files are not deleted. Signed-off-by: Stefan Beller <sbeller@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-01-05t/lib-submodule-update.sh: clarify testLibravatar Stefan Beller1-2/+2
Keep the local branch name as the upstream branch name to avoid confusion. Signed-off-by: Stefan Beller <sbeller@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-12-06Merge branch 'jt/submodule-tests-cleanup'Libravatar Junio C Hamano1-218/+125
Further test clean-up. * jt/submodule-tests-cleanup: Tests: clean up submodule recursive helpers
2017-12-06Merge branch 'sb/submodule-recursive-checkout-detach-head'Libravatar Junio C Hamano1-0/+17
"git checkout --recursive" may overwrite and rewind the history of the branch that happens to be checked out in submodule repositories, which might not be desirable. Detach the HEAD but still allow the recursive checkout to succeed in such a case. * sb/submodule-recursive-checkout-detach-head: Documentation/checkout: clarify submodule HEADs to be detached recursive submodules: detach HEAD from new state
2017-11-22Tests: clean up submodule recursive helpersLibravatar Jonathan Tan1-218/+125
This continues the work in commit d3b5a49 ("Tests: clean up and document submodule helpers", 2017-11-08). Factor out the commonalities from test_submodule_switch_recursing_with_args() and test_submodule_forced_switch_recursing_with_args() in lib-submodule-update.sh, and document their usage. Some tests differ slightly in their test assertions; I have used the superset of those assertions in that case. Signed-off-by: Jonathan Tan <jonathantanmy@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-11-08Tests: clean up and document submodule helpersLibravatar Jonathan Tan1-205/+46
Factor out the commonalities from test_submodule_switch() and test_submodule_forced_switch() in lib-submodule-update.sh, and document their usage. This also makes explicit (through the KNOWN_FAILURE_FORCED_SWITCH_TESTS variable) the fact that, currently, all functionality tested using test_submodule_forced_switch() do not correctly handle the situation in which a submodule is replaced with an ordinary directory. Signed-off-by: Jonathan Tan <jonathantanmy@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-07-25recursive submodules: detach HEAD from new stateLibravatar Stefan Beller1-0/+17
When a submodule is on a branch and in its superproject you run a recursive checkout, the branch of the submodule is updated to what the superproject checks out. This is very unexpected in the current model of Git as e.g. 'submodule update' always detaches the submodule HEAD. Despite having plans to have submodule HEADS not detached in the future, the current behavior is really bad as it doesn't match user expectations and it is not checking for loss of commits (only to be recovered via the reflog). Detach the HEAD unconditionally in the submodule when updating it. Signed-off-by: Stefan Beller <sbeller@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-06-13Merge branch 'sb/submodule-blanket-recursive'Libravatar Junio C Hamano1-4/+18
Many commands learned to pay attention to submodule.recurse configuration. * sb/submodule-blanket-recursive: builtin/fetch.c: respect 'submodule.recurse' option builtin/push.c: respect 'submodule.recurse' option builtin/grep.c: respect 'submodule.recurse' option Introduce 'submodule.recurse' option for worktree manipulators submodule loading: separate code path for .gitmodules and config overlay reset/checkout/read-tree: unify config callback for submodule recursion submodule test invocation: only pass additional arguments submodule recursing: do not write a config variable twice
2017-06-01Introduce 'submodule.recurse' option for worktree manipulatorsLibravatar Stefan Beller1-0/+12
Any command that understands '--recurse-submodules' can have its default changed to true, by setting the new 'submodule.recurse' option. This patch includes read-tree/checkout/reset for working tree manipulating commands. Later patches will cover other commands. Signed-off-by: Stefan Beller <sbeller@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-05-30submodule test invocation: only pass additional argumentsLibravatar Stefan Beller1-4/+6
In a later patch we want to introduce a config option to trigger the submodule recursing by default. As this option should be available and uniform across all commands that deal with submodules we'd want to test for this option in the submodule update library. So instead of calling the whole test set again for "git -c submodule.recurse foo" instead of "git foo --recurse-submodules", we'd only want to introduce one basic test that tests if the option is recognized and respected to not overload the test suite. Change the test functions by taking only the argument and assemble the command inside the test function by embedding the arguments into the command that is "git $arguments --recurse-submodules". It would be nice to do this for all functions in lib-submodule-update, but we cannot do that for the non-recursing tests, as there we do not just pass in a git command but whole functions. (See t3426 for example) Signed-off-by: Stefan Beller <sbeller@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-05-29Merge branch 'sb/checkout-recurse-submodules'Libravatar Junio C Hamano1-6/+1
"git checkout --recurse-submodules" did not quite work with a submodule that itself has submodules. * sb/checkout-recurse-submodules: submodule: properly recurse for read-tree and checkout submodule: avoid auto-discovery in new working tree manipulator code submodule_move_head: reuse child_process structure for futher commands
2017-05-04submodule: properly recurse for read-tree and checkoutLibravatar Stefan Beller1-6/+1
We forgot to prepare the submodule env, which is only a problem for nested submodules. See 2e5d6503bd (ls-files: fix recurse-submodules with nested submodules, 2017-04-13) for further explanation. To come up with a proper test for this, we'd need to look at nested submodules just as in that given commit. It turns out we're lucky and these tests already exist, but are marked as failing. We need to pass `--recurse-submodules` to read-tree additionally to make these tests pass. Passing that flag alone would not make the tests pass, such that this covers testing for the bug fix of the submodule env as well. Signed-off-by: Stefan Beller <sbeller@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-04-18submodule.c: submodule_move_head works with broken submodulesLibravatar Stefan Beller1-3/+20
Early on in submodule_move_head just after the check if the submodule is initialized, we need to check if the submodule is populated correctly. If the submodule is initialized but doesn't look like it is populated, this is a red flag and can indicate multiple sorts of failures: (1) The submodule may be recorded at an object name, that is missing. (2) The submodule '.git' file link may be broken and it is not pointing at a repository. In both cases we want to complain to the user in the non-forced mode, and in the forced mode ignoring the old state and just moving the submodule into its new state with a fixed '.git' file link. Signed-off-by: Stefan Beller <sbeller@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-04-18submodule.c: uninitialized submodules are ignored in recursive commandsLibravatar Stefan Beller1-0/+1
This was an oversight when working on the working tree modifying commands recursing into submodules. To test for uninitialized submodules, introduce another submodule "uninitialized_sub". Adding it via `submodule add` will activate the submodule in the preparation area (in create_lib_submodule_repo we setup all the things in submodule_update_repo), but the later tests will use a new testing repo that clones the preparation repo in which the new submodule is not initialized. By adding it to the branch "add_sub1", which is the starting point of all other branches, we have wide coverage. Signed-off-by: Stefan Beller <sbeller@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-03-16builtin/read-tree: add --recurse-submodules switchLibravatar Stefan Beller1-1/+6
A new known failure mode is introduced[1], which is actually not a failure but a feature in read-tree. Unlike checkout for which the recursive submodule tests were originally written, read-tree does warn about ignored untracked files that would be overwritten. For the sake of keeping the test library for submodules generic, just mark the test as a failure. [1] KNOWN_FAILURE_SUBMODULE_OVERWRITE_IGNORED_UNTRACKED Signed-off-by: Stefan Beller <sbeller@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-03-16builtin/checkout: add --recurse-submodules switchLibravatar Stefan Beller1-5/+21
This exposes a flag to recurse into submodules in builtin/checkout making use of the code implemented in prior patches. A new failure mode is introduced in the submodule update library, as the directory/submodule conflict is not solved in prior patches. Signed-off-by: Stefan Beller <sbeller@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-03-15lib-submodule-update.sh: define tests for recursing into submodulesLibravatar Stefan Beller1-2/+504
Currently lib-submodule-update.sh provides 2 functions test_submodule_switch and test_submodule_forced_switch that are used by a variety of tests to ensure that submodules behave as expected. The current expected behavior is that submodules are not touched at all (see 42639d2317a for the exact setup). In the future we want to teach all these commands to recurse into submodules. To do that, we'll add two testing functions to submodule-update-lib.sh: test_submodule_switch_recursing and test_submodule_forced_switch_recursing. These two functions behave in analogy to the already existing functions just with a different expectation on submodule behavior. The submodule in the working tree is expected to be updated to the recorded submodule version. The behavior is analogous to e.g. the behavior of files in a nested directory in the working tree, where a change to the working tree handles any arising directory/file conflicts just fine. Signed-off-by: Stefan Beller <sbeller@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-03-15lib-submodule-update.sh: replace sha1 by hashLibravatar Stefan Beller1-3/+3
Cleaning up code by generalising it. Currently the mailing list discusses yet again how to migrate away from sha1. Signed-off-by: Stefan Beller <sbeller@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-03-15lib-submodule-update: teach test_submodule_content the -C <dir> flagLibravatar Stefan Beller1-0/+5
Signed-off-by: Stefan Beller <sbeller@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-03-15lib-submodule-update.sh: do not use ./. as submodule remoteLibravatar Stefan Beller1-2/+13
Adding the repository itself as a submodule does not make sense in the real world. In our test suite we used to do that out of convenience in some tests as the current repository has easiest access for setting up 'just a submodule'. However this doesn't quite test the real world, so let's do not follow this pattern any further and actually create an independent repository that we can use as a submodule. When using './.' as the remote the superproject and submodule share the same objects, such that testing if a given sha1 is a valid commit works in either repository. As running commands in an unpopulated submodule fall back to the superproject, this happens in `reset_work_tree_to` to determine if we need to populate the submodule. Fix this bug by checking in the actual remote now. Signed-off-by: Stefan Beller <sbeller@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-03-15lib-submodule-update.sh: reorder create_lib_submodule_repoLibravatar Stefan Beller1-20/+29
Redraw the ASCII art describing the setup using more space, such that it is easier to understand. The leaf commits are now ordered the same way the actual code is ordered. Add empty lines to the setup code separating each of the leaf commits, each starting with a "checkout -b". Signed-off-by: Stefan Beller <sbeller@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-01-13lib-submodule-update.sh: reduce use of subshell by using "git -C"Libravatar Stefan Beller1-4/+1
We write (cd <dir> && git <cmd>) to avoid cd <dir> && git <cmd> && cd .. that allows a breakage in one part of the test script to leave the entire test process in an unexpected place. Modern version of Git allows us to do this more concisely with "git -C <dir> <cmd>". Signed-off-by: Stefan Beller <sbeller@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-07-14stash: add t3906 for submodule updatesLibravatar Jens Lehmann1-5/+18
Test that the stash apply command updates the work tree as expected for changes which don't result in conflicts. To make that work add a helper function that uses read-tree to apply the changes of the target commit to the work tree, then stashes these changes and at last applies that stash. Implement the KNOWN_FAILURE_STASH_DOES_IGNORE_SUBMODULE_CHANGES switch and reuse two other already present switches to expect the known failure that stash does ignore submodule changes. Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-07-14cherry-pick: add t3512 for submodule updatesLibravatar Jens Lehmann1-3/+12
Test that the cherry-pick command updates the work tree as expected (for submodule changes which don't result in conflicts). Set KNOWN_FAILURE_NOFF_MERGE_ATTEMPTS_TO_MERGE_REMOVED_SUBMODULE_FILES and KNOWN_FAILURE_NOFF_MERGE_DOESNT_CREATE_EMPTY_SUBMODULE_DIR to document that cherry-pick has the same --no-ff known failures merge has. Implement the KNOWN_FAILURE_CHERRY_PICK_SEES_EMPTY_COMMIT switch to expect the known failure that while cherry picking just a SHA-1 update for an ignored submodule the commit incorrectly fails with "The previous cherry-pick is now empty, possibly due to conflict resolution.". Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-07-14merge: add t7613 for submodule updatesLibravatar Jens Lehmann1-3/+21
Test that the merge command updates the work tree as expected (for submodule changes which don't result in conflicts) when used without arguments or with the '--ff', '--ff-only' and '--no-ff' flag. Implement the KNOWN_FAILURE_NOFF_MERGE_DOESNT_CREATE_EMPTY_SUBMODULE_DIR switch to expect the known failure that --no-ff merges do not create the empty submodule directory. The KNOWN_FAILURE_NOFF_MERGE_ATTEMPTS_TO_MERGE_REMOVED_SUBMODULE_FILES switch is also implemented to expect the known failure that --no-ff merges attempt to merge the new files in the former submodule directory with those of the removed submodule. Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-07-14submodules: add the lib-submodule-update.sh test libraryLibravatar Jens Lehmann1-0/+640
Add this test library to simplify covering all combinations of submodule update scenarios without having to add those to a test of each work tree manipulating command over and over again. The functions test_submodule_switch() and test_submodule_forced_switch() are intended to be called from a test script with a single argument. This argument is either a work tree manipulating command (including any command line options) or a function (when more than a single git command is needed to switch work trees from the current HEAD to another commit). This command (or function) is passed a target branch as argument. The two new functions check that each submodule transition is handled as expected, which currently means that submodule work trees are not affected until "git submodule update" is called. The "forced" variant is for commands using their '-f' or '--hard' option and expects them to overwrite local modifications as a result. Each of these two functions contains 14 tests_expect_* calls. Calling one of these test functions the first time creates a repository named "submodule_update_repo". At first it contains two files, then a single submodule is added in another commit followed by commits covering all relevant submodule modifications. This repository is newly cloned into the "submodule_update" for each test_expect_* to avoid interference between different parts of the test functions (some to-be-tested commands also manipulate refs along with the work tree, e.g. "git reset"). Follow-up commits will then call these two test functions for all work tree manipulating commands (with a combination of all their options relevant to what they do with the work tree) making sure they work as expected. Later this test library will be extended to cover merges resulting in conflicts too. Also it is intended to be easily extendable for the recursive update functionality, where even more combinations of submodule modifications have to be tested for. This version documents two bugs in current Git with expected failures: *) When a submodule is replaced with a tracked file of the same name the submodule work tree including any local modifications (and even the whole history if it uses a .git directory instead of a gitfile!) is silently removed. *) Forced work tree updates happily manipulate files in the directory of a submodule that has just been removed in the superproject (but is of course still present in the work tree due to the way submodules are currently handled). This becomes dangerous when files in the submodule directory are overwritten by files from the new superproject commit, as any modifications to the submodule files will be lost) and is expected to also destroy history in the - admittedly unlikely case - the new commit adds a file named ".git" to the submodule directory. Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>