git/t/t7400-submodule-basic.sh, branch v2.26.3

Merge branch 'pk/status-of-uncloned-submodule'

2020-02-14T20:54:23Z

The way "git submodule status" reports an initialized but not yet populated submodule has not been reimplemented correctly when a part of the "git submodule" command was rewritten in C, which has been corrected. * pk/status-of-uncloned-submodule: t7400: testcase for submodule status on unregistered inner git repos submodule: fix status of initialized but not cloned submodules t7400: add a testcase for submodule status on empty dirs

Merge branch 'hw/advice-add-nothing'

2020-02-14T20:54:19Z

Two help messages given when "git add" notices the user gave it nothing to add have been updated to use advise() API. * hw/advice-add-nothing: add: change advice config variables used by the add API add: use advise function to display hints

t7400: testcase for submodule status on unregistered inner git repos

2020-02-04T19:26:22Z

We have test coverage for "git submodule status" output in various cases, i.e. 1) not-init, not-cloned: status should initially be "missing" 2) init, not-cloned: status should be "missing" 3) not-init, cloned: status should ignore the inner git-repo 4) init, cloned: status should be "up-to-date" after update 4.1) + modified: status should be "modified" after submodule commit 4.2) + modified, committed: status should be "up-to-date" after update the case 3) is not covered yet. Test that submodule status reports an inner git repo as unknown, while it is not added to the superproject. This covers case (3). Signed-off-by: Peter Kaestle Signed-off-by: Junio C Hamano

submodule: fix status of initialized but not cloned submodules

2020-01-27T18:14:00Z

Original bash helper for "submodule status" was doing a check for initialized but not cloned submodules and prefixed the status with a minus sign in case no .git file or folder was found inside the submodule directory. This check was missed when the original port of the functionality from bash to C was done. Signed-off-by: Peter Kaestle Signed-off-by: Junio C Hamano

t7400: add a testcase for submodule status on empty dirs

2020-01-27T18:13:32Z

We have test coverage for "git submodule status" output in various cases, i.e. 1) not-init, not-cloned: status should initially be "missing" 2) init, not-cloned: status should be "missing" 3) not-init, cloned: 4) init, cloned: status should be "up-to-date" after update 4.1) + modified: status should be "modified" after submodule commit 4.2) + modified, committed: status should be "up-to-date" after update but the cases 2) and 3) are not covered. Test that submodule status reports initialized but not cloned submodules as missing to fill the gap in test coverage; this covers case (2) above, but case (3) remains uncovered. Signed-off-by: Peter Kaestle Signed-off-by: Junio C Hamano

submodule add: show 'add --dry-run' stderr when aborting

2020-01-15T18:22:24Z

Unless --force is specified, 'submodule add' checks if the destination path is ignored by calling 'git add --dry-run --ignore-missing', and, if that call fails, aborts with a custom "path is ignored" message (a slight variant of what 'git add' shows). Aborting early rather than letting the downstream 'git add' call fail is done so that the command exits before cloning into the destination path. However, in rare cases where the dry-run call fails for a reason other than the path being ignored---for example, due to a preexisting index.lock file---displaying the "ignored path" error message hides the real source of the failure. Instead of displaying the tailored "ignored path" message, let's report the standard error from the dry run to give the caller more accurate information about failures that are not due to an ignored path. For the ignored path case, this leads to the following change in the error message: The following [-path is-]{+paths are+} ignored by one of your .gitignore files: Use -f if you really want to add [-it.-]{+them.+} The new phrasing is a bit awkward, because 'submodule add' is only dealing with one destination path. Alternatively, we could continue to use the tailored message when the exit code is 1 (the expected status for a failure due to an ignored path) and relay the standard error for all other non-zero exits. That, however, risks hiding the message of unrelated failures that share an exit code of 1, so it doesn't seem worth doing just to avoid a clunkier, but still clear, error message. Signed-off-by: Kyle Meyer Signed-off-by: Junio C Hamano

Merge branch 'mg/submodule-status-from-a-subdirectory'

2019-12-05T20:52:47Z

"git submodule status" that is run from a subdirectory of the superproject did not work well, which has been corrected. * mg/submodule-status-from-a-subdirectory: submodule: fix 'submodule status' when called from a subdirectory

submodule: fix 'submodule status' when called from a subdirectory

2019-11-25T05:08:25Z

When calling `git submodule status` while in a subdirectory, we are incorrectly not detecting modified submodules and thus reporting that all of the submodules are unchanged. This is because the submodule helper is calling `diff-index` with the submodule path assuming the path is relative to the current prefix directory, however the submodule path used is actually relative to the root. Always pass NULL as the `prefix` when running diff-files on the submodule, to make sure the submodule's path is interpreted as relative to the superproject's repository root. Signed-off-by: Manish Goregaokar Signed-off-by: Junio C Hamano

tests: remove "cat foo" before "test_i18ngrep bar foo"

2019-10-07T01:17:44Z

Some tests print a file before searching for a pattern using test_i18ngrep. This is useful when debugging tests with --verbose when the pattern is not found as expected. Since 63b1a175ee (t: make 'test_i18ngrep' more informative on failure, 2018-02-08) test_i18ngrep already shows the contents of a file that doesn't match the expected pattern, though. So don't bother doing the same unconditionally up-front. The contents are not interesting if the expected pattern is found, and showing it twice if it doesn't match is of no use. Signed-off-by: René Scharfe Signed-off-by: Junio C Hamano

submodule: refuse to add repository with no commits

2019-04-10T03:52:48Z

When the path given to 'git submodule add' is an existing repository that is not in the index, the repository is passed to 'git add'. If this repository doesn't have a commit checked out, we don't get a useful result: there is no subproject OID to track, and any untracked files in the sub-repository are added as blobs in the top-level repository. To avoid getting into this state, abort if the path is a repository that doesn't have a commit checked out. Note that this check must come before the 'git add --dry-run' check because the next commit will make 'git add' fail when given a repository that doesn't have a commit checked out. Signed-off-by: Kyle Meyer Signed-off-by: Junio C Hamano