summaryrefslogtreecommitdiff
path: root/t/lib-submodule-update.sh
AgeCommit message (Collapse)AuthorFilesLines
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-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>