submodule: drop the top-level requirement

With the recent discussion, I wondered how hard it would be to add SUBDIRECTORY_OK=Yes to git-submodule.sh and it doesn't seem that bad.

Note that this series currently lacks both tests and documentation updates. Also I have made no attempt to change the output from any commands, so submodule paths are always printed relative to the top-level of the repository.

Consider this series a proof-of-concept, to see whether I'm on completely the wrong course.

John Keeping (2):
rev-parse: add --filename-prefix option
submodule: drop the top-level requirement

 builtin/rev-parse.c | 17 ++++++++++++-----
 git-submodule.sh    |  7 +++++++
 2 files changed, 19 insertions(+), 5 deletions(-)

This adds a prefix string to any filename arguments encountered after it has been specified.

Quoted 2 lines · John Keeping

This adds a prefix string to any filename arguments encountered after it has been specified.

I assume this is a way of passing the prefix in? In that case, I think a good UI would be

	git rev-parse --prefix=Documentation/ <usual rev-parse args>

That sounds like a useful thing and would make the meaning very clear.

How does this interact with the following options?

* --resolve-git-dir some/relative/path

* master:./path

As for the patch itself, I haven't looked at it closely. My only immediate reaction is that I wish it touched Documentation/ and t/. :)

Yes (ish), the intended usage is something like this:

prefix=$(git rev-parse --show-prefix)
cd_to_toplevel
... parse options here ...
# Convert remaining arguments (filenames) into top-level paths:
eval "set $(git rev-parse --prefix "$prefix" --sq -- "$@")"

The "ish" is that my current implementation introduced a new variable instead of simply resetting the existing "prefix" variable, which I assume is what you mean.

That is probably simpler than my
implementation, but loses the ability to be at an intermediate level, for example:

    cd Documentation/
    eval "set $(git rev-parse --prefix technical/ --sq -- api-strbuf.txt)"

Quoted 8 lines · John Keeping

Yes (ish), the intended usage is something like this:

prefix=$(git rev-parse --show-prefix)
cd_to_toplevel
... parse options here ...
# Convert remaining arguments (filenames) into top-level paths:
eval "set $(git rev-parse --prefix "$prefix" --sq -- "$@")"

Quoted 3 lines

The "ish" is that my current implementation introduced a new variable instead of simply resetting the existing "prefix" variable, which I assume is what you mean.

This is very sensible.

Quoted 14 lines · Junio C Hamano

Quoted 11 lines · John Keeping

Yes (ish), the intended usage is something like this:

prefix=$(git rev-parse --show-prefix)
cd_to_toplevel
... parse options here ...
# Convert remaining arguments (filenames) into top-level paths:
eval "set $(git rev-parse --prefix "$prefix" --sq -- "$@")"

The "ish" is that my current implementation introduced a new variable instead of simply resetting the existing "prefix" variable, which I assume is what you mean.

Quoted 1 line

This is very sensible.

Which bit specifically? I assume you agree with the intended usage, but do you also mean that resetting the prefix returned from setup_git_directory is the right way to approach this?

This adds a prefix string to any filename arguments encountered after it has been specified.

Signed-off-by John Keeping <[email protected]>

---

+--prefix <arg>::

Documentation/git-rev-parse.txt +3 -0

+	Behave as if 'git rev-parse' was invoked from the `<arg>`
+	subdirectory of the working tree.  Any relative filenames are
+	resolved as if they are prefixed by `<arg>` and will be printed

Quoted 5 lines · John Keeping

This adds a prefix string to any filename arguments encountered after it has been specified.

Signed-off-by John Keeping <[email protected]>

---

Stale subject?

Quoted 4 lines

+--prefix <arg>::

Documentation/git-rev-parse.txt +3 -0

+	Behave as if 'git rev-parse' was invoked from the `<arg>`
+	subdirectory of the working tree.  Any relative filenames are
+	resolved as if they are prefixed by `<arg>` and will be printed

Documentation/git-rev-parse.txt OPTIONS · line 75

Quoted 10 lines

Documentation/git-rev-parse.txt +10 -0

+	in that form.
++
+This can be used to convert arguments to a command run in a subdirectory
+so that they can still be used after moving to the top-level of the
+repository.  For example:
++
+----
+prefix=$(git rev-parse --show-prefix)
+cd "$(git rev-parse --show-toplevel)"
+eval "set -- $(git rev-parse --sq --prefix "$prefix" "$@")"

I think you should tighten rev-parse parameter to reject options and revisions, especially as an example to teach how to use it. When the user said

git mylog -U20 master..next -- README

inside Documentation/ directory, "git-mylog" script would want to see README prefixed with Documentation/ but want to see -U20 or master..next untouched.

Historically, rev-parse was a way to sift
options and args meant for rev-list from those mant for diff-tree so that a variant of

	git rev-list $(git rev-parse --revs) "$@" |
        git diff-tree --stdin $(git rev-parse --no-revs)

can be used to implement such "git mylog" script.

I think "--no-revs --no-flags" is how you ask it to give you only the paths, but I am writing from memory so please double check.

Having said all that.

Existing scripts (e.g. "git am") do this kind of things without such an option added to rev-parse. They first do:

    prefix=$(git rev-parse --show-prefix)

and refer to "$prefix/$1", "$prefix/$2", etc., I think.

Is this option really necessary to update "git submodule"? Don't we have a much better idea which parameter holds user-supplied path in the script than having rev-parse make a guess on the entire "$@"?

It's not guessing on all of "$@" in git-submodule - we know that everything left is a path.

This adds a prefix string to any filename arguments encountered after it has been specified.

Quoted 2 lines · John Keeping

This adds a prefix string to any filename arguments encountered after it has been specified.

Very nice. I thought we'd have to resort to path mangling in shell to fix git-submodule.sh. Glad to see that we can go with something cleaner.

Perhaps pull some bits from your nice Documentation into the commit message?

builtin/rev-parse.c static void show_datestring(const char *flag, const char *datestr) · line 215

Quoted 10 lines

builtin/rev-parse.c +1 -1

index f267a1d..de894c7 100644
@@ -212,11 +212,17 @@ static void show_datestring(const char *flag, const char *datestr)
        show(buffer);
 }
 
-static int show_file(const char *arg)
+static int show_file(const char *arg, int output_prefix)

Okay, so you've essentially patched show_file() to accept an additional argument, and modified callers to call with this additional argument. I suppose show_(rev|reference|default|flag|rev|with_type|datestring|abbrev) don't need to be patched, as they are path-independent.

builtin/rev-parse.c static void show_datestring(const char *flag, const char *datestr) · line 225

Quoted 11 lines

builtin/rev-parse.c +7 -1

 {
        show_default();
        if ((filter & (DO_NONFLAGS|DO_NOREV)) == (DO_NONFLAGS|DO_NOREV)) {
-               show(arg);
+               if (output_prefix) {
+                       const char *prefix = startup_info->prefix;
+                       show(prefix_filename(prefix,
+                                            prefix ? strlen(prefix) : 0,
+                                            arg));
+               } else
+                       show(arg);

Uh, why do you need output_prefix? If startup_info->prefix is set, use it. Is startup_info->prefix set by anyone by cmd_rev_parse()?

Quoted 11 lines

builtin/rev-parse.c +5 -0

@@ -470,6 +476,7 @@ N_("git rev-parse --parseopt [options] -- [<args>...]\n"
 int cmd_rev_parse(int argc, const char **argv, const char *prefix)

@@ -535,6 +542,13 @@ int cmd_rev_parse(int argc, const char **argv, const char *prefix)
                                i++;
                                continue;
                        }
+                       if (!strcmp(arg, "--prefix")) {
+                               prefix = argv[i+1];
+                               startup_info->prefix = prefix;
+                               output_prefix = 1;
+                               i++;

builtin/rev-parse.c int cmd_rev_parse(int argc, const char **argv, const char *prefix) · line 551

Quoted 2 lines

builtin/rev-parse.c +2 -0

+                               continue;
+                       }

Wait, why isn't prefix filled in when run_builtin() calls this? Oh,
right: because we didn't mark this builtin with RUN_SETUP or RUN_SETUP_GENTLY. Okay, now why didn't we change that? Because it would be a major problem (all our scripts would break) if rev-parse did cd-to-toplevel.

Why are you setting prefix to argv[i+1], and then setting startup_info->prefix to that? Is anyone else in cmd_rev_parse() going to use it?

builtin/rev-parse.c int cmd_rev_parse(int argc, const char **argv, const char *prefix) · line 554

Quoted 3 lines

builtin/rev-parse.c +3 -0

+prefix=$(git rev-parse --show-prefix)
+cd "$(git rev-parse --show-toplevel)"
+eval "set -- $(git rev-parse --sq --prefix "$prefix" "$@")"

I'm wondering if you need such a convoluted usage though. Will you ever need to specify a prefix by hand that is different from what git rev-parse --show-toplevel returns? If not, why don't you just rev-parse --emulate-toplevel, and get rid of specifying prefix by hand altogether? Then again, this is a plumbing command, so the simplicity is probably more valuable.

t/t1513-rev-parse-prefix.sh line 18

Quoted 8 lines

t/t1513-rev-parse-prefix.sh new file +3 -0

new file mode 100755
index 0000000..5ef48d2
+test_expect_success 'empty prefix -- file' '
+       git rev-parse --prefix "" -- top sub1/file1 >actual &&
+       cat <<-EOF >expected &&

Nit: when you're not putting in variables, you can cat <<-\EOF.

t/t1513-rev-parse-prefix.sh line 48

Quoted 3 lines

t/t1513-rev-parse-prefix.sh new file +3 -0

+test_expect_success 'empty prefix HEAD:./path' '
+       git rev-parse --prefix "" HEAD:./top >actual &&
+       git rev-parse HEAD:top >expected &&

Nit: why did you change "./top" to "top"? Your --prefix option doesn't require you to change your arguments accordingly, does it?

Review

Quoted 1 line · John Keeping

(quoted diff) +1 -0

+	eval "set $(git rev-parse --sq --prefix "$wt_prefix" -- "$@")"

This may be handier than having to do the "for arg" loop git-am uses yourself.

Quoted 7 lines

git-submodule.sh +0 -0

 	(
 		git ls-files --error-unmatch --stage -- "$@" ||
 		echo "unmatched pathspec exists"

@@ -335,6 +339,8 @@ cmd_add()
 		usage
 	fi
 

git-submodule.sh cmd_add() · line 342

Quoted 1 line

git-submodule.sh +1 -0

+	sm_path="$wt_prefix$sm_path"

But this is doing fine without "rev-parse --prefix" at all.

Use the new rev-parse --prefix option to process all paths given to the submodule command, dropping the requirement that it be run from the top-level of the repository.

Quoted 3 lines · John Keeping

Use the new rev-parse --prefix option to process all paths given to the submodule command, dropping the requirement that it be run from the top-level of the repository.

Yay!

git-submodule.sh resolve_relative_url () · line 118

Quoted 9 lines

git-submodule.sh +1 -0

index 79bfaac..bbf7983 100755
@@ -112,6 +115,7 @@ resolve_relative_url ()
 #
 module_list()
 {
+       eval "set $(git rev-parse --sq --prefix "$wt_prefix" -- "$@")"

Nit: Why not use "--" to disambiguate between options and arguments, like you showed in your intended usage?

So, this essentially converts all the paths specified in "$@" to toplevel-relative paths. Beautiful, as this is practically the only change you require in each function.

git-submodule.sh cmd_add() · line 342

Quoted 1 line

git-submodule.sh +1 -0

+       sm_path="$wt_prefix$sm_path"

Wait, isn't sm_path the value of submodule.<name>.path in .gitmodules?
Why does it need to be prefixed?

git-submodule.sh cmd_summary() { · line 951

Quoted 5 lines

git-submodule.sh +1 -0

@@ -942,6 +948,7 @@ cmd_summary() {
        fi
 
        cd_to_toplevel
+       eval "set $(git rev-parse --sq --prefix "$wt_prefix" -- "$@")"

Um, what about other functions? Yeah, it looks like all of them except this one call module_list().

t/t7400-submodule-basic.sh test_expect_success 'submodule add with ./, /.. and // in path' ' · line 217

Quoted 11 lines

t/t7400-submodule-basic.sh +3 -0

index ff26535..7795f21 100755
@@ -212,6 +212,23 @@ test_expect_success 'submodule add with ./, /.. and // in path' '
        test_cmp empty untracked
 '
 
+test_expect_success 'submodule add in subdir' '
+       echo "refs/heads/master" >expect &&
+       >empty &&

Nit: Use : >empty. It's clearer.

t/t7400-submodule-basic.sh test_expect_success 'submodule add with ./, /.. and // in path' ' · line 219

Quoted 2 lines

t/t7400-submodule-basic.sh +2 -0

+       (
+               mkdir addtest/sub &&

Why is the mkdir inside the subshell? The next statement (cd) onwards should be in the subshell, to save you cd'ing back.

t/t7400-submodule-basic.sh test_expect_success 'submodule add with ./, /.. and // in path' ' · line 225

Quoted 6 lines

t/t7400-submodule-basic.sh +6 -0

+               cd addtest/sub &&
+               git submodule add "$submodurl" ../realsubmod3 &&
+               git submodule init
+       ) &&
+
+       rm -f heads head untracked &&

Huh? What is this in the middle? The next statement (call to inspect) write-truncates them anyway, so this is unnecessary.

Changes since v2:
- Rewrite commit message
- Add a new test for 'prefix ignored with HEAD:top'
- Use '<<-\EOF' where appropriate in t1513

Quoted 4 lines · John Keeping

Changes since v2:
- Rewrite commit message
- Add a new test for 'prefix ignored with HEAD:top'
- Use '<<-\EOF' where appropriate in t1513

Thanks for the re-roll.

In the previous iteration, I wasn't sure this was the right approach because I thought it would be better to pass RUN_SETUP and let run_builtin_command() take care of the prefix-setting. Unfortunately, as 5410a02 (git-rev-parse --parseopt, 2007-11-06) indicates, we have to run setup_git_directory() in cmd_rev_parse() after parsing --parseopt, as 'git rev-parse --parseopt' can be run outside a git repository. You might want to include this note in your commit message for the benefit of other readers.

Other than that, I just have one small suggestion: it's possible to avoid passing output_prefix around, and simplify show_file() a bit if we acknowledge that printing "--" is not the same as printing a file (although the condition is the same). Would you like to squash this in?

Signed-off-by Ramkumar Ramachandra <[email protected]>

-- 8< --

builtin/rev-parse.c +17 -9

index de894c7..7e69b3f 100644
@@ -29,6 +29,7 @@ static int abbrev;
 static int abbrev_ref;
 static int abbrev_ref_strict;
 static int output_sq;
+static int output_prefix;
 
 /*
  * Some arguments are relevant "revision" arguments,

@@ -212,15 +213,13 @@ static void show_datestring(const char *flag, const char *datestr)
 	show(buffer);
 }
 
-static int show_file(const char *arg, int output_prefix)
+static int show_file(const char *arg)
 {
 	show_default();
 	if ((filter & (DO_NONFLAGS|DO_NOREV)) == (DO_NONFLAGS|DO_NOREV)) {
 		if (output_prefix) {
 			const char *prefix = startup_info->prefix;
-			show(prefix_filename(prefix,
-					     prefix ? strlen(prefix) : 0,
-					     arg));
+			show(prefix_filename(prefix, strlen(prefix), arg));
 		} else
 			show(arg);
 		return 1;

@@ -228,6 +227,16 @@ static int show_file(const char *arg, int output_prefix)
 	return 0;
 }
 
+static int show_dashdash()
+{
+	show_default();
+	if ((filter & (DO_NONFLAGS | DO_NOREV)) == (DO_NONFLAGS | DO_NOREV)) {
+		show("--");
+		return 1;
+	}
+	return 0;
+}
+
 static int try_difference(const char *arg)
 {
 	char *dotdot;

@@ -476,7 +485,6 @@ N_("git rev-parse --parseopt [options] -- [<args>...]\n"
 int cmd_rev_parse(int argc, const char **argv, const char *prefix)
 {
 	int i, as_is = 0, verify = 0, quiet = 0, revs_count = 0, type = 0;
-	int output_prefix = 0;
 	unsigned char sha1[20];
 	const char *name = NULL;
 

@@ -510,7 +518,7 @@ int cmd_rev_parse(int argc, const char **argv, const char *prefix)
 		const char *arg = argv[i];
 
 		if (as_is) {
-			if (show_file(arg, output_prefix) && as_is < 2)
+			if (show_file(arg) && as_is < 2)
 				verify_filename(prefix, arg, 0);
 			continue;
 		}

@@ -534,7 +542,7 @@ int cmd_rev_parse(int argc, const char **argv, const char *prefix)
 				as_is = 2;
 				/* Pass on the "--" if we show anything but files.. */
 				if (filter & (DO_FLAGS | DO_REVS))
-					show_file(arg, 0);
+					show_dashdash();
 				continue;
 			}
 			if (!strcmp(arg, "--default")) {

@@ -543,7 +551,7 @@ int cmd_rev_parse(int argc, const char **argv, const char *prefix)
 				continue;
 			}
 			if (!strcmp(arg, "--prefix")) {
-				prefix = argv[i+1];
+				prefix = argv[i + 1];
 				startup_info->prefix = prefix;
 				output_prefix = 1;
 				i++;

@@ -768,7 +776,7 @@ int cmd_rev_parse(int argc, const char **argv, const char *prefix)
 		if (verify)
 			die_no_single_rev(quiet);
 		as_is = 1;
-		if (!show_file(arg, output_prefix))
+		if (!show_file(arg))
 			continue;
 		verify_filename(prefix, arg, 1);
 	}

I'm not actually sure this is better. I'm more afraid of the condition for outputting files changing in the future than of passing output_prefix around, so I'd much rather keep that condition in one place.

If you really feel strongly about it, I'd prefer to extract the if condition to a function and use that directly when deciding whether to print "--".

[Also, you introduce a potential segfault via passing a NULL prefix to strlen.]

Quoted 8 lines · John Keeping

I'm not actually sure this is better. I'm more afraid of the condition for outputting files changing in the future than of passing output_prefix around, so I'd much rather keep that condition in one place.

If you really feel strongly about it, I'd prefer to extract the if condition to a function and use that directly when deciding whether to print "--".

Yeah, it would probably make more sense to extract the conditional. I just thought it was unnecessary to pass the argument around, but feel free to go either way on this one.

Quoted 2 lines

[Also, you introduce a potential segfault via passing a NULL prefix to strlen.]

Isn't prefix guaranteed to be set by setup_git_directory()? If I wanted to check it nevertheless, I'd probably put in a die("internal error") before this line. Feel free to go either way though.

It looks to me like setup_git_directory() returns NULL if we're at the top of the working tree so we do need that check. I suspect that's so that "!prefix" does the right thing.

git-submodule.sh +6 -0

+relative_path ()
+{
+	local target curdir result
+	target=$1
+	curdir=${2-$wt_prefix}
+	curdir=${curdir%/}

Quoted 14 lines · John Keeping

git-submodule.sh +14 -0

+relative_path ()
+{
+	local target curdir result
+	target=$1
+	curdir=${2-$wt_prefix}
+	curdir=${curdir%/}
+	result=
+
+	while test -n "$curdir"
+	do
+		case "$target" in
+		"$curdir/"*)
+			target=${target#$curdir/}
+			break

git-submodule.sh resolve_relative_url () · line 133

Quoted 2 lines

git-submodule.sh +2 -0

+			;;
+		esac

Could $curdir have glob wildcard to throw this part of the logic off? It is OK to have limitations like "you cannot have a glob characters in your path to submodule working tree" (at least until we start rewriting these in C or Perl or Python), but we need to be aware of them.

Review

Quoted 3 lines

module_list()
{

(quoted diff) +1 -0

+	eval "set $(git rev-parse --sq --prefix "$wt_prefix" -- "$@")"

An efficient reuse of "--" ;-)

t/t7401-submodule-summary.sh EOF · line 58

Quoted 11 lines

t/t7401-submodule-summary.sh +11 -0

+test_expect_success 'run summary from subdir' '
+	mkdir sub &&
+	(
+		cd sub &&
+		git submodule summary >../actual
+	) &&
+	cat >expected <<-EOF &&
+* ../sm1 0000000...$head1 (2):
+  > Add foo2
+
+EOF

It somewhat looks strange to start with "<<-EOF" and then not to indent the body nor EOF.

Quoted 16 lines · Junio C Hamano

Quoted 14 lines · John Keeping

git-submodule.sh +14 -0

+relative_path ()
+{
+	local target curdir result
+	target=$1
+	curdir=${2-$wt_prefix}
+	curdir=${curdir%/}
+	result=
+
+	while test -n "$curdir"
+	do
+		case "$target" in
+		"$curdir/"*)
+			target=${target#$curdir/}
+			break

Quoted 8 lines

git-submodule.sh resolve_relative_url () · line 133

Quoted 2 lines

git-submodule.sh +2 -0

+			;;
+		esac

Could $curdir have glob wildcard to throw this part of the logic off? It is OK to have limitations like "you cannot have a glob characters in your path to submodule working tree" (at least until we start rewriting these in C or Perl or Python), but we need to be aware of them.

I think the use of "#" instead of "##" saves us here because even with a wildcard in $curdir the case statement matches literally,

Quoted 26 lines · John Keeping

Quoted 16 lines · Junio C Hamano

Quoted 14 lines · John Keeping

git-submodule.sh +14 -0

+relative_path ()
+{
+	local target curdir result
+	target=$1
+	curdir=${2-$wt_prefix}
+	curdir=${curdir%/}
+	result=
+
+	while test -n "$curdir"
+	do
+		case "$target" in
+		"$curdir/"*)
+			target=${target#$curdir/}
+			break

Quoted 8 lines

git-submodule.sh resolve_relative_url () · line 133

Quoted 2 lines

git-submodule.sh +2 -0

+			;;
+		esac

Could $curdir have glob wildcard to throw this part of the logic off? It is OK to have limitations like "you cannot have a glob characters in your path to submodule working tree" (at least until we start rewriting these in C or Perl or Python), but we need to be aware of them.

Quoted 2 lines

I think the use of "#" instead of "##" saves us here because even with a wildcard in $curdir the case statement matches literally,

If you have curdir=a*b and target=adropb/c/d/e, the chopping itself

	target=${target#$curdir/}

would happily chop "adropb/" from the target, but because the dq around "$curdir/"* in the case arm label enforces that target must literally match curdir followed by a slash, we do not even come to the chomping part.

I still have not convinced myself that it is impossible for somebody more clever than I to craft a pair of target and curdir that breaks it, though. (target="a*b/c/d", curdir="a*b") is correctly chopped, so that is not it.

Why not just replace the six-liner by this one-liner:

		target=${target#"$curdir"/}

Quoted 3 lines · Johannes Sixt

Why not just replace the six-liner by this one-liner:

		target=${target#"$curdir"/}

Simple enough ;-)

Quoted 5 lines

Quoted 3 lines

Why not just replace the six-liner by this one-liner:

		target=${target#"$curdir"/}

Simple enough ;-)

This seems to have arrived on next without this fix, so here's a patch on top.

 git-submodule.sh | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

git-submodule.sh +0 -0

index 0eee703..db9f260 100755

Quoted 12 lines · John Keeping

Quoted 5 lines

Quoted 3 lines

Why not just replace the six-liner by this one-liner:

		target=${target#"$curdir"/}

Simple enough ;-)

This seems to have arrived on next without this fix, so here's a patch on top.

 git-submodule.sh | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

git-submodule.sh relative_path () · line 133

Quoted 13 lines

git-submodule.sh +1 -1

index 0eee703..db9f260 100755
@@ -127,7 +127,7 @@ relative_path ()
 	do
 		case "$target" in
 		"$curdir/"*)
-			target=${target#$curdir/}
+			target=${target#"$curdir"/}
 			break
 			;;
 		esac

J6t meant a patch to remove the entire case...esac and replace it with a single liner (target=${target#"$curdir"/}).

Quoted 2 lines

J6t meant a patch to remove the entire case...esac and replace it with a single liner (target=${target#"$curdir"/}).

Ah, I missed the "six-liner" part. But that doesn't work because we break out of the do...while loop when "$target" starts with "$curdir/" and replacing the case statement will remove that.

Use the new rev-parse --prefix option to process all paths given to the submodule command, dropping the requirement that it be run from the top-level of the repository.

Signed-off-by John Keeping <[email protected]>

---

t/t7400-submodule-basic.sh +0 -0

index ff26535..ca0a6ab 100755

t/t7400-submodule-basic.sh +17 -0

+       echo "refs/heads/master" >expect &&
+       >empty &&
+
+       mkdir addtest/sub &&
+       (
+               cd addtest/sub &&
+               git submodule add "$submodurl" ../realsubmod3 &&
+               git submodule init
+       ) &&
+
+       rm -f heads head untracked &&
+       inspect addtest/realsubmod3 ../.. &&
+       test_cmp expect heads &&
+       test_cmp expect head &&
+       test_cmp empty untracked
+'
+
 test_expect_success 'setup - add an example entry to .gitmodules' '
        GIT_CONFIG=.gitmodules \
        git config submodule.example.url git://example.com/init.git

t/t7400-submodule-basic.sh +8 -0

+       mkdir sub &&
+       (
+               cd sub &&
+               git submodule status >../list
+       ) &&
+       grep "^ $rev1" list
+'
+
 test_expect_success 'status should be "modified" after submodule commit' '
        (
                cd init &&

t/t7401-submodule-summary.sh +0 -0

index 30b429e..992b66b 100755

t/t7401-submodule-summary.sh +13 -0

+       mkdir sub &&
+       (
+               cd sub &&
+               git submodule summary >../actual
+       ) &&
+       cat >expected <<-EOF &&
+* ../sm1 0000000...$head1 (2):
+  > Add foo2
+
+EOF
+       test_cmp expected actual
+'
+
 commit_file sm1 &&
 head2=$(add_file sm1 foo3)