git@vger.kernel.org list mirror (unofficial, one of many)
 help / color / mirror / code / Atom feed
* [PATCH v6 0/5] teach submodules to know they're submodules
@ 2021-11-17  0:56 Emily Shaffer
  2021-11-17  0:56 ` [PATCH v6 1/5] t7400-submodule-basic: modernize inspect() helper Emily Shaffer
                   ` (6 more replies)
  0 siblings, 7 replies; 14+ messages in thread
From: Emily Shaffer @ 2021-11-17  0:56 UTC (permalink / raw)
  To: git
  Cc: Emily Shaffer, Albert Cui, Phillip Wood, Johannes Schindelin,
	Ævar Arnfjörð Bjarmason, Junio C Hamano,
	Matheus Tavares Bernardino, Jonathan Nieder, Jacob Keller,
	Atharva Raykar, Derrick Stolee, Jonathan Tan

For the original cover letter, see
https://lore.kernel.org/git/20210611225428.1208973-1-emilyshaffer%40google.com.

CI run: https://github.com/nasamuffin/git/actions/runs/1469463328

Since v5:

A couple things. Firstly, a semantics change *back* to the semantics of
v3 - we map from gitdir to gitdir, *not* from common dir to common dir,
so that theoretically a submodule with multiple worktrees in multiple
superproject worktrees will be able to figure out which worktree of the
superproject it's in. (Realistically, that's not really possible right
now, but I'd like to change that soon.)

Secondly, a rewording of comments and commit messages to indicate that
this isn't a cache of some expensive operation, but rather intended to
be the source of truth for all submodules. I also added a fifth commit
rewriting `git rev-parse --show-superproject-working-tree` to
demonstrate what that means in practice - but from a practical
standpoint, I'm a little worried about that fifth patch. More details in
the patch 5 description.

I did discuss Ævar's idea of relying on in-process filesystem digging to
find the superproject's gitdir with the rest of the Google team, but in
the end decided that there are some worries about filesystem digging in
this way (namely, some ugly interactions with network drives that are
actually already an issue for Googler Linux machines). Plus, the allure
of being able to definitively know that we're a submodule is pretty
strong. ;) But overall, this is the direction I'd prefer to keep going
in, rather than trying to guess from the filesystem going forward.

Since v4:

The only real change here is a slight semantics change to map from
<submodule gitdir> to <superproject common git dir>. In every case
*except* for when the superproject has a worktree, this changes nothing.
For the case when the superproject has a worktree, this means that now
submodules will refer to the general superproject common dir (e.g. no
worktree-specific refs or configs or whatnot).

I *think* that because a submodule should exist in the context of the
common dir, not the worktree gitdir, that is ok. However, it does mean
it would be difficult to do something like sharing a config specific to
the worktree (the initial goal of this series).

$ROOT/.git
$ROOT/.git/config.superproject <- shared by $ROOT/.git/modules/sub
$ROOT/.git/modules/sub <- points to $ROOT/.git
$ROOT/.git/worktrees/wt
$ROOT/.git/worktrees/wt/config.superproject <- contains a certain config-based pre-commit hook

If the submodule only knows about the common dir, that is tough, because
the submodule would basically have to guess which worktree it's in from
its own path. There would be no way for '$WT/sub' to inherit
'$ROOT/.git/worktrees/wt/config.superproject'.

That said... right now, we don't support submodules in worktrees very
well at all. A submodule in a worktree will get a brand new gitdir in
$ROOT/.git/worktrees/modules/ (and that brand new gitdir would point to
the super's common dir). So I think we can punt on this entire question
until we teach submodules and worktrees to play more gracefully together
(it's on my long list...), and at that time we can probably introduce a
pointer from $ROOT/.git/modules/sub/worktrees/wt/ to
$ROOT/.git/worktrees/wt/....

Or, to summarize the long ramble above: "this is still kind of weird
with worktrees, but let's fix it later when we fix worktrees more
thoroughly".

(More rambling about worktree weirdness here:
https://lore.kernel.org/git/YYRaII8YWVxlBqsF%40google.com )


Since v3, a pretty major change: the semantics of
submodule.superprojectGitDir has changed, to point from the submodule's
gitdir to the superproject's gitdir (in v3 and earlier, we kept a path
from the submodule's *worktree* to the superproject's gitdir instead).
This cleans up some of the confusions about the behavior when a
submodule worktree moves around in the superproject's tree, or in a
future when we support submodules having multiple worktrees.

I also tried to simplify the tests to use 'test-tool path-utils
relative_path' everywhere - I think that makes them much more clear for
a test reader, but if you're reviewing and it isn't obvious what we're
testing for, please speak up.

I think this is pretty mature and there was a lot of general agreement
that the gitdir->gitdir association was the way to go, so please be
brutal and look for nits, leaks, etc. this round ;)
[/v4 cover letter]

Emily Shaffer (5):
  t7400-submodule-basic: modernize inspect() helper
  introduce submodule.superprojectGitDir record
  submodule: record superproject gitdir during absorbgitdirs
  submodule: record superproject gitdir during 'update'
  submodule: use config to find superproject worktree

 Documentation/config/submodule.txt |  12 ++++
 builtin/submodule--helper.c        |  11 +++
 git-submodule.sh                   |  15 ++++
 submodule.c                        | 108 ++++++++++++++++++++++++++++-
 t/t1500-rev-parse.sh               |   9 +++
 t/t7400-submodule-basic.sh         |  54 ++++++++-------
 t/t7406-submodule-update.sh        |  27 ++++++++
 t/t7412-submodule-absorbgitdirs.sh |  82 +++++++++++++++++++++-
 8 files changed, 290 insertions(+), 28 deletions(-)

Range-diff against v5:
1:  6ff10beaf2 = 1:  f1b08a7057 t7400-submodule-basic: modernize inspect() helper
2:  d4f4627585 ! 2:  d46c8439ab introduce submodule.superprojectGitDir record
    @@ Commit message
     
         By using a relative path instead of an absolute path, we can move the
         superproject directory around on the filesystem without breaking the
    -    submodule's cache. And by using the path from gitdir to gitdir, we can
    +    submodule's pointer. And by using the path from gitdir to gitdir, we can
         move the submodule within the superproject's tree structure without
    -    breaking the submodule's cache, too. Finally, by pointing at
    -    "get_git_common_dir()" instead of "get_git_dir()", we ensure the link
    -    will refer to the parent repo, not to a specific worktree.
    +    breaking the submodule's pointer, too. Finally, by pointing at the
    +    superproject's worktree gitdir (if it exists), we ensure that we can
    +    tell which worktree contains our submodule.
     
         Since this hint value is only introduced during new submodule creation
         via `git submodule add`, though, there is more work to do to allow the
         record to be created at other times.
     
    -    If the new config is present, we can do some optional value-added
    -    behavior, like letting "git status" print additional info about the
    -    submodule's status in relation to its superproject, or like letting the
    -    superproject and submodule share an additional config file separate from
    -    either one's local config.
    +    Once this new config is reliably in place, we can use it to know
    +    definitively that we are working in a submodule, and to know which
    +    superproject we are a submodule of. This allows us to do some
    +    value-added behavior, like letting "git status" print additional info
    +    about the submodule's status in relation to its superproject, or like
    +    letting the superproject and submodule share an additional config file
    +    separate from either one's local config.
     
         Signed-off-by: Emily Shaffer <emilyshaffer@google.com>
         Helped-by: Junio C Hamano <gitster@pobox.com>
    @@ Documentation/config/submodule.txt: submodule.alternateErrorStrategy::
     +
     +submodule.superprojectGitDir::
     +	The relative path from the submodule's gitdir to its superproject's
    -+	common dir. When Git is run in a repository, it usually makes no
    ++	gitdir. When Git is run in a repository, it usually makes no
     +	difference whether this repository is standalone or a submodule, but if
     +	this configuration variable is present, additional behavior may be
     +	possible, such as "git status" printing additional information about
    @@ builtin/submodule--helper.c: static int clone_submodule(struct module_clone_data
      		git_config_set_in_file(p, "submodule.alternateErrorStrategy",
      				       error_strategy);
      
    -+	git_config_set_in_file(p, "submodule.superprojectGitdir",
    -+			       relative_path(absolute_path(get_git_common_dir()),
    ++	/*
    ++	 * Set the path from submodule's new gitdir to superproject's gitdir.
    ++	 * The latter may be a worktree gitdir. However, it is not possible for
    ++	 * the submodule to have a worktree-specific gitdir or config at clone
    ++	 * time, because "extensions.worktreeConfig" is only valid when set in
    ++	 * the local gitconfig, which the brand new submodule does not have yet.
    ++	 */
    ++	git_config_set_in_file(p, "submodule.superprojectGitDir",
    ++			       relative_path(absolute_path(get_git_dir()),
     +					     sm_gitdir, &sb));
     +
      	free(sm_alternate);
    @@ t/t7400-submodule-basic.sh: submodurl=$(pwd -P)
     +	# Ensure that submodule.superprojectGitDir contains the path from the
     +	# submodule's gitdir to the superproject's gitdir.
     +
    -+	super_abs_gitdir=$(git -C "$super_dir" rev-parse --path-format=absolute --git-common-dir) &&
    -+	sub_abs_gitdir=$(git -C "$sub_dir" rev-parse --path-format=absolute --git-common-dir) &&
    ++	super_abs_gitdir=$(git -C "$super_dir" rev-parse --absolute-git-dir) &&
    ++	sub_abs_gitdir=$(git -C "$sub_dir" rev-parse --absolute-git-dir) &&
     +
     +	[ "$(git -C "$sub_dir" config --get submodule.superprojectGitDir)" = \
     +	  "$(test-tool path-utils relative_path "$super_abs_gitdir" \
3:  2dae297943 ! 3:  63ddaf5608 submodule: record superproject gitdir during absorbgitdirs
    @@ submodule.c: static void relocate_single_git_dir_into_superproject(const char *p
      	char *old_git_dir = NULL, *real_old_git_dir = NULL, *real_new_git_dir = NULL;
      	struct strbuf new_gitdir = STRBUF_INIT;
      	const struct submodule *sub;
    ++	struct config_set sub_cs;
     +	struct strbuf config_path = STRBUF_INIT, sb = STRBUF_INIT;
    ++	int tmp;
      
      	if (submodule_uses_worktrees(path))
      		die(_("relocate_gitdir for submodule '%s' with "
    @@ submodule.c: static void relocate_single_git_dir_into_superproject(const char *p
      
      	relocate_gitdir(path, real_old_git_dir, real_new_git_dir);
      
    -+	/* cache pointer to superproject's gitdir */
    ++	/*
    ++	 * Note location of superproject's gitdir. Because the submodule already
    ++	 * has a gitdir and local config, we can store this pointer from
    ++	 * worktree config to worktree config, if the submodule has
    ++	 * extensions.worktreeConfig set.
    ++	 */
     +	strbuf_addf(&config_path, "%s/config", real_new_git_dir);
    ++	git_configset_init(&sub_cs);
    ++	git_configset_add_file(&sub_cs, config_path.buf);
    ++	/* return 0 indicates config was found - we have a worktree config */
    ++	if (!git_configset_get_bool(&sub_cs, "extensions.worktreeConfig", &tmp))
    ++		strbuf_addstr(&config_path, ".worktree");
    ++
     +	git_config_set_in_file(config_path.buf, "submodule.superprojectGitdir",
    -+			       relative_path(absolute_path(get_git_common_dir()),
    ++			       relative_path(absolute_path(get_git_dir()),
     +					     real_new_git_dir, &sb));
     +
    ++	git_configset_clear(&sub_cs);
     +	strbuf_release(&config_path);
     +	strbuf_release(&sb);
      	free(old_git_dir);
    @@ t/t7412-submodule-absorbgitdirs.sh: test_expect_success 'absorbing fails for a s
     +	# absorb the git dir
     +	git submodule absorbgitdirs sub4 &&
     +
    -+	# make sure the submodule cached the superproject gitdir correctly
    -+	submodule_gitdir="$(git -C sub4 rev-parse --path-format=absolute --git-common-dir)" &&
    -+	superproject_gitdir="$(git rev-parse --path-format=absolute --git-common-dir)" &&
    ++	# make sure the submodule noted the superproject gitdir correctly
    ++	submodule_gitdir="$(git -C sub4 rev-parse --absolute-git-dir)" &&
    ++	superproject_gitdir="$(git rev-parse --absolute-git-dir)" &&
     +
     +	test-tool path-utils relative_path "$superproject_gitdir" \
     +		"$submodule_gitdir" >expect &&
    @@ t/t7412-submodule-absorbgitdirs.sh: test_expect_success 'absorbing fails for a s
     +	test_cmp expect actual
     +	)
     +'
    ++
    ++test_expect_success 'absorbgitdirs works with a submodule with worktree config' '
    ++	# reuse the worktree of the superproject
    ++	(
    ++	cd wt &&
    ++
    ++	# create a new unembedded git dir
    ++	git init sub5 &&
    ++	test_commit -C sub5 first &&
    ++	git submodule add ./sub5 &&
    ++	test_tick &&
    ++
    ++	# turn on worktree configs for submodule
    ++	git -C sub5 config extensions.worktreeConfig true &&
    ++
    ++	# absorb the git dir
    ++	git submodule absorbgitdirs sub5 &&
    ++
    ++	# make sure the submodule noted the superproject gitdir correctly
    ++	submodule_gitdir="$(git -C sub5 rev-parse --absolute-git-dir)" &&
    ++	superproject_gitdir="$(git rev-parse --absolute-git-dir)" &&
    ++
    ++	test-tool path-utils relative_path "$superproject_gitdir" \
    ++		"$submodule_gitdir" >expect &&
    ++	git -C sub5 config submodule.superprojectGitDir >actual &&
    ++
    ++	test_cmp expect actual &&
    ++
    ++	# make sure the config went into the submodule config.worktree
    ++	test_file_not_empty "$submodule_gitdir/config.worktree"
    ++	)
    ++'
     +
      test_done
4:  f0412d6d34 ! 4:  33a582ef13 submodule: record superproject gitdir during 'update'
    @@ Metadata
      ## Commit message ##
         submodule: record superproject gitdir during 'update'
     
    -    A recorded hint path to the superproject's gitdir might be added during
    +    A recorded path to the superproject's gitdir might be added during
         'git submodule add', but in some cases - like submodules which were
         created before 'git submodule add' learned to record that info - it might
         be useful to update the hint. Let's do it during 'git submodule
    @@ git-submodule.sh: cmd_update()
      			;;
      		esac
      
    -+		# Cache a pointer to the superproject's common dir. This may have
    -+		# changed, unless it's a fresh clone. Writes it to worktree
    -+		# if applicable, otherwise to local.
    ++		# Store a poitner to the superproject's gitdir. This may have
    ++		# changed, unless it's a fresh clone. Write to worktree if
    ++		# applicable, and point to superproject's worktree gitdir if
    ++		# applicable.
     +		if test -z "$just_cloned"
     +		then
     +			sm_gitdir="$(git -C "$sm_path" rev-parse --absolute-git-dir)"
     +			relative_gitdir="$(git rev-parse --path-format=relative \
     +							 --prefix "${sm_gitdir}" \
    -+							 --git-common-dir)"
    ++							 --git-dir)"
     +
     +			git -C "$sm_path" config --worktree \
     +				submodule.superprojectgitdir "$relative_gitdir"
    @@ t/t7406-submodule-update.sh: test_expect_success 'submodule update --quiet passe
     +	 git -C submodule config --unset submodule.superprojectGitdir &&
     +	 git submodule update &&
     +	 test-tool path-utils relative_path \
    -+		"$(git rev-parse --path-format=absolute --git-common-dir)" \
    -+		"$(git -C submodule rev-parse --path-format=absolute --git-common-dir)" >expect &&
    ++		"$(git rev-parse --absolute-git-dir)" \
    ++		"$(git -C submodule rev-parse --absolute-git-dir)" >expect &&
     +	 git -C submodule config submodule.superprojectGitdir >actual &&
     +	 test_cmp expect actual
     +	)
     +'
    ++
    ++test_expect_success 'submodule update uses config.worktree if applicable' '
    ++	(cd super &&
    ++	 git -C submodule config --unset submodule.superprojectGitDir &&
    ++	 git -C submodule config extensions.worktreeConfig true &&
    ++	 git submodule update &&
    ++	 test-tool path-utils relative_path \
    ++		"$(git rev-parse --absolute-git-dir)" \
    ++		"$(git -C submodule rev-parse --absolute-git-dir)" >expect &&
    ++	 git -C submodule config submodule.superprojectGitdir >actual &&
    ++	 test_cmp expect actual &&
    ++
    ++	 test_file_not_empty "$(git -C submodule rev-parse --absolute-git-dir)/config.worktree"
    ++	)
    ++'
     +
      test_done
-:  ---------- > 5:  a8b5d40a77 submodule: use config to find superproject worktree
-- 
2.34.0.rc1.387.gb447b232ab-goog


^ permalink raw reply	[flat|nested] 14+ messages in thread

* [PATCH v6 1/5] t7400-submodule-basic: modernize inspect() helper
  2021-11-17  0:56 [PATCH v6 0/5] teach submodules to know they're submodules Emily Shaffer
@ 2021-11-17  0:56 ` Emily Shaffer
  2021-11-17  0:56 ` [PATCH v6 2/5] introduce submodule.superprojectGitDir record Emily Shaffer
                   ` (5 subsequent siblings)
  6 siblings, 0 replies; 14+ messages in thread
From: Emily Shaffer @ 2021-11-17  0:56 UTC (permalink / raw)
  To: git; +Cc: Emily Shaffer

Since the inspect() helper in the submodule-basic test suite was
written, 'git -C <dir>' was added. By using -C, we no longer need a
reference to the base directory for the test. This simplifies callsites,
and will make the addition of other arguments in later patches more
readable.

Signed-off-by: Emily Shaffer <emilyshaffer@google.com>
---
 t/t7400-submodule-basic.sh | 40 +++++++++++++++-----------------------
 1 file changed, 16 insertions(+), 24 deletions(-)

diff --git a/t/t7400-submodule-basic.sh b/t/t7400-submodule-basic.sh
index cb1b8e35db..d69a5c0032 100755
--- a/t/t7400-submodule-basic.sh
+++ b/t/t7400-submodule-basic.sh
@@ -107,23 +107,15 @@ test_expect_success 'setup - repository to add submodules to' '
 # generates, which will expand symbolic links.
 submodurl=$(pwd -P)
 
-listbranches() {
-	git for-each-ref --format='%(refname)' 'refs/heads/*'
-}
-
 inspect() {
-	dir=$1 &&
-	dotdot="${2:-..}" &&
-
-	(
-		cd "$dir" &&
-		listbranches >"$dotdot/heads" &&
-		{ git symbolic-ref HEAD || :; } >"$dotdot/head" &&
-		git rev-parse HEAD >"$dotdot/head-sha1" &&
-		git update-index --refresh &&
-		git diff-files --exit-code &&
-		git clean -n -d -x >"$dotdot/untracked"
-	)
+	sub_dir=$1 &&
+
+	git -C "$sub_dir" for-each-ref --format='%(refname)' 'refs/heads/*' >heads &&
+	{ git -C "$sub_dir" symbolic-ref HEAD || :; } >head &&
+	git -C "$sub_dir" rev-parse HEAD >head-sha1 &&
+	git -C "$sub_dir" update-index --refresh &&
+	git -C "$sub_dir" diff-files --exit-code &&
+	git -C "$sub_dir" clean -n -d -x >untracked
 }
 
 test_expect_success 'submodule add' '
@@ -146,7 +138,7 @@ test_expect_success 'submodule add' '
 	) &&
 
 	rm -f heads head untracked &&
-	inspect addtest/submod ../.. &&
+	inspect addtest/submod &&
 	test_cmp expect heads &&
 	test_cmp expect head &&
 	test_must_be_empty untracked
@@ -248,7 +240,7 @@ test_expect_success 'submodule add --branch' '
 	) &&
 
 	rm -f heads head untracked &&
-	inspect addtest/submod-branch ../.. &&
+	inspect addtest/submod-branch &&
 	test_cmp expect-heads heads &&
 	test_cmp expect-head head &&
 	test_must_be_empty untracked
@@ -264,7 +256,7 @@ test_expect_success 'submodule add with ./ in path' '
 	) &&
 
 	rm -f heads head untracked &&
-	inspect addtest/dotsubmod/frotz ../../.. &&
+	inspect addtest/dotsubmod/frotz &&
 	test_cmp expect heads &&
 	test_cmp expect head &&
 	test_must_be_empty untracked
@@ -280,7 +272,7 @@ test_expect_success 'submodule add with /././ in path' '
 	) &&
 
 	rm -f heads head untracked &&
-	inspect addtest/dotslashdotsubmod/frotz ../../.. &&
+	inspect addtest/dotslashdotsubmod/frotz &&
 	test_cmp expect heads &&
 	test_cmp expect head &&
 	test_must_be_empty untracked
@@ -296,7 +288,7 @@ test_expect_success 'submodule add with // in path' '
 	) &&
 
 	rm -f heads head untracked &&
-	inspect addtest/slashslashsubmod/frotz ../../.. &&
+	inspect addtest/slashslashsubmod/frotz &&
 	test_cmp expect heads &&
 	test_cmp expect head &&
 	test_must_be_empty untracked
@@ -312,7 +304,7 @@ test_expect_success 'submodule add with /.. in path' '
 	) &&
 
 	rm -f heads head untracked &&
-	inspect addtest/realsubmod ../.. &&
+	inspect addtest/realsubmod &&
 	test_cmp expect heads &&
 	test_cmp expect head &&
 	test_must_be_empty untracked
@@ -328,7 +320,7 @@ test_expect_success 'submodule add with ./, /.. and // in path' '
 	) &&
 
 	rm -f heads head untracked &&
-	inspect addtest/realsubmod2 ../.. &&
+	inspect addtest/realsubmod2 &&
 	test_cmp expect heads &&
 	test_cmp expect head &&
 	test_must_be_empty untracked
@@ -359,7 +351,7 @@ test_expect_success 'submodule add in subdirectory' '
 	) &&
 
 	rm -f heads head untracked &&
-	inspect addtest/realsubmod3 ../.. &&
+	inspect addtest/realsubmod3 &&
 	test_cmp expect heads &&
 	test_cmp expect head &&
 	test_must_be_empty untracked
-- 
2.34.0.rc1.387.gb447b232ab-goog


^ permalink raw reply	[flat|nested] 14+ messages in thread

* [PATCH v6 2/5] introduce submodule.superprojectGitDir record
  2021-11-17  0:56 [PATCH v6 0/5] teach submodules to know they're submodules Emily Shaffer
  2021-11-17  0:56 ` [PATCH v6 1/5] t7400-submodule-basic: modernize inspect() helper Emily Shaffer
@ 2021-11-17  0:56 ` Emily Shaffer
  2021-11-17 23:43   ` Jonathan Tan
  2021-11-17  0:56 ` [PATCH v6 3/5] submodule: record superproject gitdir during absorbgitdirs Emily Shaffer
                   ` (4 subsequent siblings)
  6 siblings, 1 reply; 14+ messages in thread
From: Emily Shaffer @ 2021-11-17  0:56 UTC (permalink / raw)
  To: git; +Cc: Emily Shaffer, Junio C Hamano

Teach submodules a reference to their superproject's gitdir. This allows
us to A) know that we're running from a submodule, and B) have a
shortcut to the superproject's vitals, for example, configs.

By using a relative path instead of an absolute path, we can move the
superproject directory around on the filesystem without breaking the
submodule's pointer. And by using the path from gitdir to gitdir, we can
move the submodule within the superproject's tree structure without
breaking the submodule's pointer, too. Finally, by pointing at the
superproject's worktree gitdir (if it exists), we ensure that we can
tell which worktree contains our submodule.

Since this hint value is only introduced during new submodule creation
via `git submodule add`, though, there is more work to do to allow the
record to be created at other times.

Once this new config is reliably in place, we can use it to know
definitively that we are working in a submodule, and to know which
superproject we are a submodule of. This allows us to do some
value-added behavior, like letting "git status" print additional info
about the submodule's status in relation to its superproject, or like
letting the superproject and submodule share an additional config file
separate from either one's local config.

Signed-off-by: Emily Shaffer <emilyshaffer@google.com>
Helped-by: Junio C Hamano <gitster@pobox.com>
---
 Documentation/config/submodule.txt | 12 +++++++++++
 builtin/submodule--helper.c        | 11 ++++++++++
 t/t7400-submodule-basic.sh         | 32 ++++++++++++++++++++----------
 3 files changed, 45 insertions(+), 10 deletions(-)

diff --git a/Documentation/config/submodule.txt b/Documentation/config/submodule.txt
index ee454f8126..61d975745e 100644
--- a/Documentation/config/submodule.txt
+++ b/Documentation/config/submodule.txt
@@ -91,3 +91,15 @@ submodule.alternateErrorStrategy::
 	`ignore`, `info`, `die`. Default is `die`. Note that if set to `ignore`
 	or `info`, and if there is an error with the computed alternate, the
 	clone proceeds as if no alternate was specified.
+
+submodule.superprojectGitDir::
+	The relative path from the submodule's gitdir to its superproject's
+	gitdir. When Git is run in a repository, it usually makes no
+	difference whether this repository is standalone or a submodule, but if
+	this configuration variable is present, additional behavior may be
+	possible, such as "git status" printing additional information about
+	this submodule's status with respect to its superproject. This config
+	should only be present in projects which are submodules, but is not
+	guaranteed to be present in every submodule, so only optional
+	value-added behavior should be linked to it. It is set automatically
+	during submodule creation.
diff --git a/builtin/submodule--helper.c b/builtin/submodule--helper.c
index e630f0c730..24f0ef2a78 100644
--- a/builtin/submodule--helper.c
+++ b/builtin/submodule--helper.c
@@ -1838,6 +1838,17 @@ static int clone_submodule(struct module_clone_data *clone_data)
 		git_config_set_in_file(p, "submodule.alternateErrorStrategy",
 				       error_strategy);
 
+	/*
+	 * Set the path from submodule's new gitdir to superproject's gitdir.
+	 * The latter may be a worktree gitdir. However, it is not possible for
+	 * the submodule to have a worktree-specific gitdir or config at clone
+	 * time, because "extensions.worktreeConfig" is only valid when set in
+	 * the local gitconfig, which the brand new submodule does not have yet.
+	 */
+	git_config_set_in_file(p, "submodule.superprojectGitDir",
+			       relative_path(absolute_path(get_git_dir()),
+					     sm_gitdir, &sb));
+
 	free(sm_alternate);
 	free(error_strategy);
 
diff --git a/t/t7400-submodule-basic.sh b/t/t7400-submodule-basic.sh
index d69a5c0032..3d146491df 100755
--- a/t/t7400-submodule-basic.sh
+++ b/t/t7400-submodule-basic.sh
@@ -109,12 +109,24 @@ submodurl=$(pwd -P)
 
 inspect() {
 	sub_dir=$1 &&
+	super_dir=$2 &&
 
 	git -C "$sub_dir" for-each-ref --format='%(refname)' 'refs/heads/*' >heads &&
 	{ git -C "$sub_dir" symbolic-ref HEAD || :; } >head &&
 	git -C "$sub_dir" rev-parse HEAD >head-sha1 &&
 	git -C "$sub_dir" update-index --refresh &&
 	git -C "$sub_dir" diff-files --exit-code &&
+
+	# Ensure that submodule.superprojectGitDir contains the path from the
+	# submodule's gitdir to the superproject's gitdir.
+
+	super_abs_gitdir=$(git -C "$super_dir" rev-parse --absolute-git-dir) &&
+	sub_abs_gitdir=$(git -C "$sub_dir" rev-parse --absolute-git-dir) &&
+
+	[ "$(git -C "$sub_dir" config --get submodule.superprojectGitDir)" = \
+	  "$(test-tool path-utils relative_path "$super_abs_gitdir" \
+						"$sub_abs_gitdir")" ] &&
+
 	git -C "$sub_dir" clean -n -d -x >untracked
 }
 
@@ -138,7 +150,7 @@ test_expect_success 'submodule add' '
 	) &&
 
 	rm -f heads head untracked &&
-	inspect addtest/submod &&
+	inspect addtest/submod addtest &&
 	test_cmp expect heads &&
 	test_cmp expect head &&
 	test_must_be_empty untracked
@@ -240,7 +252,7 @@ test_expect_success 'submodule add --branch' '
 	) &&
 
 	rm -f heads head untracked &&
-	inspect addtest/submod-branch &&
+	inspect addtest/submod-branch addtest &&
 	test_cmp expect-heads heads &&
 	test_cmp expect-head head &&
 	test_must_be_empty untracked
@@ -256,7 +268,7 @@ test_expect_success 'submodule add with ./ in path' '
 	) &&
 
 	rm -f heads head untracked &&
-	inspect addtest/dotsubmod/frotz &&
+	inspect addtest/dotsubmod/frotz addtest &&
 	test_cmp expect heads &&
 	test_cmp expect head &&
 	test_must_be_empty untracked
@@ -272,7 +284,7 @@ test_expect_success 'submodule add with /././ in path' '
 	) &&
 
 	rm -f heads head untracked &&
-	inspect addtest/dotslashdotsubmod/frotz &&
+	inspect addtest/dotslashdotsubmod/frotz addtest &&
 	test_cmp expect heads &&
 	test_cmp expect head &&
 	test_must_be_empty untracked
@@ -288,7 +300,7 @@ test_expect_success 'submodule add with // in path' '
 	) &&
 
 	rm -f heads head untracked &&
-	inspect addtest/slashslashsubmod/frotz &&
+	inspect addtest/slashslashsubmod/frotz addtest &&
 	test_cmp expect heads &&
 	test_cmp expect head &&
 	test_must_be_empty untracked
@@ -304,7 +316,7 @@ test_expect_success 'submodule add with /.. in path' '
 	) &&
 
 	rm -f heads head untracked &&
-	inspect addtest/realsubmod &&
+	inspect addtest/realsubmod addtest &&
 	test_cmp expect heads &&
 	test_cmp expect head &&
 	test_must_be_empty untracked
@@ -320,7 +332,7 @@ test_expect_success 'submodule add with ./, /.. and // in path' '
 	) &&
 
 	rm -f heads head untracked &&
-	inspect addtest/realsubmod2 &&
+	inspect addtest/realsubmod2 addtest &&
 	test_cmp expect heads &&
 	test_cmp expect head &&
 	test_must_be_empty untracked
@@ -351,7 +363,7 @@ test_expect_success 'submodule add in subdirectory' '
 	) &&
 
 	rm -f heads head untracked &&
-	inspect addtest/realsubmod3 &&
+	inspect addtest/realsubmod3 addtest &&
 	test_cmp expect heads &&
 	test_cmp expect head &&
 	test_must_be_empty untracked
@@ -492,7 +504,7 @@ test_expect_success 'update should work when path is an empty dir' '
 	git submodule update -q >update.out &&
 	test_must_be_empty update.out &&
 
-	inspect init &&
+	inspect init . &&
 	test_cmp expect head-sha1
 '
 
@@ -551,7 +563,7 @@ test_expect_success 'update should checkout rev1' '
 	echo "$rev1" >expect &&
 
 	git submodule update init &&
-	inspect init &&
+	inspect init . &&
 
 	test_cmp expect head-sha1
 '
-- 
2.34.0.rc1.387.gb447b232ab-goog


^ permalink raw reply	[flat|nested] 14+ messages in thread

* [PATCH v6 3/5] submodule: record superproject gitdir during absorbgitdirs
  2021-11-17  0:56 [PATCH v6 0/5] teach submodules to know they're submodules Emily Shaffer
  2021-11-17  0:56 ` [PATCH v6 1/5] t7400-submodule-basic: modernize inspect() helper Emily Shaffer
  2021-11-17  0:56 ` [PATCH v6 2/5] introduce submodule.superprojectGitDir record Emily Shaffer
@ 2021-11-17  0:56 ` Emily Shaffer
  2021-11-17  0:57 ` [PATCH v6 4/5] submodule: record superproject gitdir during 'update' Emily Shaffer
                   ` (3 subsequent siblings)
  6 siblings, 0 replies; 14+ messages in thread
From: Emily Shaffer @ 2021-11-17  0:56 UTC (permalink / raw)
  To: git; +Cc: Emily Shaffer

Already during 'git submodule add' we record a pointer to the
superproject's gitdir. However, this doesn't help brand-new
submodules created with 'git init' and later absorbed with 'git
submodule absorbgitdirs'. Let's start adding that pointer during 'git
submodule absorbgitdirs' too.

Signed-off-by: Emily Shaffer <emilyshaffer@google.com>
---
 submodule.c                        | 23 +++++++++
 t/t7412-submodule-absorbgitdirs.sh | 82 +++++++++++++++++++++++++++++-
 2 files changed, 103 insertions(+), 2 deletions(-)

diff --git a/submodule.c b/submodule.c
index c689070524..d7395c7551 100644
--- a/submodule.c
+++ b/submodule.c
@@ -2097,6 +2097,9 @@ static void relocate_single_git_dir_into_superproject(const char *path)
 	char *old_git_dir = NULL, *real_old_git_dir = NULL, *real_new_git_dir = NULL;
 	struct strbuf new_gitdir = STRBUF_INIT;
 	const struct submodule *sub;
+	struct config_set sub_cs;
+	struct strbuf config_path = STRBUF_INIT, sb = STRBUF_INIT;
+	int tmp;
 
 	if (submodule_uses_worktrees(path))
 		die(_("relocate_gitdir for submodule '%s' with "
@@ -2127,6 +2130,26 @@ static void relocate_single_git_dir_into_superproject(const char *path)
 
 	relocate_gitdir(path, real_old_git_dir, real_new_git_dir);
 
+	/*
+	 * Note location of superproject's gitdir. Because the submodule already
+	 * has a gitdir and local config, we can store this pointer from
+	 * worktree config to worktree config, if the submodule has
+	 * extensions.worktreeConfig set.
+	 */
+	strbuf_addf(&config_path, "%s/config", real_new_git_dir);
+	git_configset_init(&sub_cs);
+	git_configset_add_file(&sub_cs, config_path.buf);
+	/* return 0 indicates config was found - we have a worktree config */
+	if (!git_configset_get_bool(&sub_cs, "extensions.worktreeConfig", &tmp))
+		strbuf_addstr(&config_path, ".worktree");
+
+	git_config_set_in_file(config_path.buf, "submodule.superprojectGitdir",
+			       relative_path(absolute_path(get_git_dir()),
+					     real_new_git_dir, &sb));
+
+	git_configset_clear(&sub_cs);
+	strbuf_release(&config_path);
+	strbuf_release(&sb);
 	free(old_git_dir);
 	free(real_old_git_dir);
 	free(real_new_git_dir);
diff --git a/t/t7412-submodule-absorbgitdirs.sh b/t/t7412-submodule-absorbgitdirs.sh
index 1cfa150768..5753f90268 100755
--- a/t/t7412-submodule-absorbgitdirs.sh
+++ b/t/t7412-submodule-absorbgitdirs.sh
@@ -30,7 +30,17 @@ test_expect_success 'absorb the git dir' '
 	git status >actual.1 &&
 	git -C sub1 rev-parse HEAD >actual.2 &&
 	test_cmp expect.1 actual.1 &&
-	test_cmp expect.2 actual.2
+	test_cmp expect.2 actual.2 &&
+
+	# make sure the submodule cached the superproject gitdir correctly
+	submodule_gitdir="$(git -C sub1 rev-parse --path-format=absolute --git-common-dir)" &&
+	superproject_gitdir="$(git rev-parse --path-format=absolute --git-common-dir)" &&
+
+	test-tool path-utils relative_path "$superproject_gitdir" \
+		"$submodule_gitdir" >expect &&
+	git -C sub1 config submodule.superprojectGitDir >actual &&
+
+	test_cmp expect actual
 '
 
 test_expect_success 'absorbing does not fail for deinitialized submodules' '
@@ -61,7 +71,16 @@ test_expect_success 'absorb the git dir in a nested submodule' '
 	git status >actual.1 &&
 	git -C sub1/nested rev-parse HEAD >actual.2 &&
 	test_cmp expect.1 actual.1 &&
-	test_cmp expect.2 actual.2
+	test_cmp expect.2 actual.2 &&
+
+	sub1_gitdir="$(git -C sub1 rev-parse --path-format=absolute --git-common-dir)" &&
+	sub1_nested_gitdir="$(git -C sub1/nested rev-parse --path-format=absolute --git-common-dir)" &&
+
+	test-tool path-utils relative_path "$sub1_gitdir" "$sub1_nested_gitdir" \
+		>expect &&
+	git -C sub1/nested config submodule.superprojectGitDir >actual &&
+
+	test_cmp expect actual
 '
 
 test_expect_success 're-setup nested submodule' '
@@ -130,4 +149,63 @@ test_expect_success 'absorbing fails for a submodule with multiple worktrees' '
 	test_i18ngrep "not supported" error
 '
 
+test_expect_success 'absorbgitdirs works when called from a superproject worktree' '
+	# set up a worktree of the superproject
+	git worktree add wt &&
+	(
+	cd wt &&
+
+	# create a new unembedded git dir
+	git init sub4 &&
+	test_commit -C sub4 first &&
+	git submodule add ./sub4 &&
+	test_tick &&
+
+	# absorb the git dir
+	git submodule absorbgitdirs sub4 &&
+
+	# make sure the submodule noted the superproject gitdir correctly
+	submodule_gitdir="$(git -C sub4 rev-parse --absolute-git-dir)" &&
+	superproject_gitdir="$(git rev-parse --absolute-git-dir)" &&
+
+	test-tool path-utils relative_path "$superproject_gitdir" \
+		"$submodule_gitdir" >expect &&
+	git -C sub4 config submodule.superprojectGitDir >actual &&
+
+	test_cmp expect actual
+	)
+'
+
+test_expect_success 'absorbgitdirs works with a submodule with worktree config' '
+	# reuse the worktree of the superproject
+	(
+	cd wt &&
+
+	# create a new unembedded git dir
+	git init sub5 &&
+	test_commit -C sub5 first &&
+	git submodule add ./sub5 &&
+	test_tick &&
+
+	# turn on worktree configs for submodule
+	git -C sub5 config extensions.worktreeConfig true &&
+
+	# absorb the git dir
+	git submodule absorbgitdirs sub5 &&
+
+	# make sure the submodule noted the superproject gitdir correctly
+	submodule_gitdir="$(git -C sub5 rev-parse --absolute-git-dir)" &&
+	superproject_gitdir="$(git rev-parse --absolute-git-dir)" &&
+
+	test-tool path-utils relative_path "$superproject_gitdir" \
+		"$submodule_gitdir" >expect &&
+	git -C sub5 config submodule.superprojectGitDir >actual &&
+
+	test_cmp expect actual &&
+
+	# make sure the config went into the submodule config.worktree
+	test_file_not_empty "$submodule_gitdir/config.worktree"
+	)
+'
+
 test_done
-- 
2.34.0.rc1.387.gb447b232ab-goog


^ permalink raw reply	[flat|nested] 14+ messages in thread

* [PATCH v6 4/5] submodule: record superproject gitdir during 'update'
  2021-11-17  0:56 [PATCH v6 0/5] teach submodules to know they're submodules Emily Shaffer
                   ` (2 preceding siblings ...)
  2021-11-17  0:56 ` [PATCH v6 3/5] submodule: record superproject gitdir during absorbgitdirs Emily Shaffer
@ 2021-11-17  0:57 ` Emily Shaffer
  2021-11-17  0:57 ` [PATCH v6 5/5] submodule: use config to find superproject worktree Emily Shaffer
                   ` (2 subsequent siblings)
  6 siblings, 0 replies; 14+ messages in thread
From: Emily Shaffer @ 2021-11-17  0:57 UTC (permalink / raw)
  To: git; +Cc: Emily Shaffer

A recorded path to the superproject's gitdir might be added during
'git submodule add', but in some cases - like submodules which were
created before 'git submodule add' learned to record that info - it might
be useful to update the hint. Let's do it during 'git submodule
update', when we already have a handle to the superproject while calling
operations on the submodules.

Signed-off-by: Emily Shaffer <emilyshaffer@google.com>
---
 git-submodule.sh            | 15 +++++++++++++++
 t/t7406-submodule-update.sh | 27 +++++++++++++++++++++++++++
 2 files changed, 42 insertions(+)

diff --git a/git-submodule.sh b/git-submodule.sh
index 652861aa66..7c247bee7f 100755
--- a/git-submodule.sh
+++ b/git-submodule.sh
@@ -449,6 +449,21 @@ cmd_update()
 			;;
 		esac
 
+		# Store a poitner to the superproject's gitdir. This may have
+		# changed, unless it's a fresh clone. Write to worktree if
+		# applicable, and point to superproject's worktree gitdir if
+		# applicable.
+		if test -z "$just_cloned"
+		then
+			sm_gitdir="$(git -C "$sm_path" rev-parse --absolute-git-dir)"
+			relative_gitdir="$(git rev-parse --path-format=relative \
+							 --prefix "${sm_gitdir}" \
+							 --git-dir)"
+
+			git -C "$sm_path" config --worktree \
+				submodule.superprojectgitdir "$relative_gitdir"
+		fi
+
 		if test -n "$recursive"
 		then
 			(
diff --git a/t/t7406-submodule-update.sh b/t/t7406-submodule-update.sh
index 11cccbb333..b42a339982 100755
--- a/t/t7406-submodule-update.sh
+++ b/t/t7406-submodule-update.sh
@@ -1061,4 +1061,31 @@ test_expect_success 'submodule update --quiet passes quietness to fetch with a s
 	)
 '
 
+test_expect_success 'submodule update adds superproject gitdir to older repos' '
+	(cd super &&
+	 git -C submodule config --unset submodule.superprojectGitdir &&
+	 git submodule update &&
+	 test-tool path-utils relative_path \
+		"$(git rev-parse --absolute-git-dir)" \
+		"$(git -C submodule rev-parse --absolute-git-dir)" >expect &&
+	 git -C submodule config submodule.superprojectGitdir >actual &&
+	 test_cmp expect actual
+	)
+'
+
+test_expect_success 'submodule update uses config.worktree if applicable' '
+	(cd super &&
+	 git -C submodule config --unset submodule.superprojectGitDir &&
+	 git -C submodule config extensions.worktreeConfig true &&
+	 git submodule update &&
+	 test-tool path-utils relative_path \
+		"$(git rev-parse --absolute-git-dir)" \
+		"$(git -C submodule rev-parse --absolute-git-dir)" >expect &&
+	 git -C submodule config submodule.superprojectGitdir >actual &&
+	 test_cmp expect actual &&
+
+	 test_file_not_empty "$(git -C submodule rev-parse --absolute-git-dir)/config.worktree"
+	)
+'
+
 test_done
-- 
2.34.0.rc1.387.gb447b232ab-goog


^ permalink raw reply	[flat|nested] 14+ messages in thread

* [PATCH v6 5/5] submodule: use config to find superproject worktree
  2021-11-17  0:56 [PATCH v6 0/5] teach submodules to know they're submodules Emily Shaffer
                   ` (3 preceding siblings ...)
  2021-11-17  0:57 ` [PATCH v6 4/5] submodule: record superproject gitdir during 'update' Emily Shaffer
@ 2021-11-17  0:57 ` Emily Shaffer
  2021-11-17 11:43 ` [RFC PATCH 0/2] submodule: test what happens if submodule.superprojectGitDir isn't around Ævar Arnfjörð Bjarmason
  2021-11-17 23:28 ` [PATCH v6 0/5] teach submodules to know they're submodules Jonathan Tan
  6 siblings, 0 replies; 14+ messages in thread
From: Emily Shaffer @ 2021-11-17  0:57 UTC (permalink / raw)
  To: git; +Cc: Emily Shaffer

Now that submodule.superprojectGitDir is being treated as the point of
truth for whether a repo is a submodule or not, let's use it in `git
rev-parse --show-superproject-working-tree`.

Signed-off-by: Emily Shaffer <emilyshaffer@google.com>

---

This commit may be more of an RFC - to demonstrate what life looks like
if we use submodule.superprojectGitDir as the source of truth. But since
'git rev-parse --show-superproject-working-tree' is used in a lot of
scripts in the wild[1], I'm not so sure it's a great example.

To be honest, I'd prefer to die("Try running 'git submodule update'")
here, but I don't think that's very script-friendly. However, falling
back on the old implementation kind of undermines the idea of treating
submodule.superprojectGitDir as the point of truth. One thought I did
have was to put that error message in builtin/rev-parse.c instead, and
print it to stderr (per usual with user-visible messages) so it doesn't
interfere with scripts, but gives a hint for debugging.

Another thought - captured by the NEEDSWORK in the diff - was that we
could "heal" by adding that config after we know the worktree of the
superproject.

Or, it could be that it won't be a problem for a long time, as anybody
running 'git submodule update' will eventually have that config
specified - that's why I included the traces, so we could try and get an
understanding of how long repos remain in this state where they have
submodules but nobody ran 'git submodule update'. But that will only
give me visibility into submodule users at Google, who we expect to be
making a lot of workflow changes soon, anyway.

1: https://github.com/search?q=%22--show-superproject-working-tree%22&type=code
---
 submodule.c          | 85 +++++++++++++++++++++++++++++++++++++++++++-
 t/t1500-rev-parse.sh |  9 +++++
 2 files changed, 93 insertions(+), 1 deletion(-)

diff --git a/submodule.c b/submodule.c
index d7395c7551..ad95cdda07 100644
--- a/submodule.c
+++ b/submodule.c
@@ -2236,7 +2236,7 @@ void absorb_git_dir_into_superproject(const char *path,
 	}
 }
 
-int get_superproject_working_tree(struct strbuf *buf)
+static int get_superproject_working_tree_from_fs(struct strbuf *buf)
 {
 	struct child_process cp = CHILD_PROCESS_INIT;
 	struct strbuf sb = STRBUF_INIT;
@@ -2320,6 +2320,89 @@ int get_superproject_working_tree(struct strbuf *buf)
 	return ret;
 }
 
+int get_superproject_working_tree(struct strbuf *buf)
+{
+	char *super_gitdir = NULL;
+	const char *cwd = xgetcwd();
+	struct child_process cp = CHILD_PROCESS_INIT;
+	struct strbuf absolute_super_gitdir = STRBUF_INIT;
+	struct strbuf out = STRBUF_INIT;
+	struct string_list lines = STRING_LIST_INIT_NODUP;
+	struct string_list_item *it = NULL;
+	const char *wt_prefix = "worktree ";
+	int rc = 0;
+
+
+	/* Do we know we have a superproject? */
+	if (git_config_get_string("submodule.superprojectgitdir", &super_gitdir))
+		goto fallback;
+
+	strbuf_addf(&absolute_super_gitdir, "%s/%s", get_git_dir(), super_gitdir);
+
+	/*
+	 * NEEDSWORK: This is a child process call because worktree.c still
+	 * relies heavily on the_repository. If we can make worktree.c work with
+	 * a repository object - or, better yet, a gitdir path alone - then we
+	 * can drop the child process and ask worktree.c directly.
+	 *
+	 * Alternatively, if 'git worktree' learns a way to say 'the worktree
+	 * associated with this gitdir' instead of 'all worktrees', that would
+	 * be clearer because we could skip the foreach below.
+	 */
+
+	/* Get the output of `git worktree list` from that superproject */
+	prepare_other_repo_env(&cp.env_array, absolute_super_gitdir.buf);
+	strvec_pushl(&cp.args, "-C", absolute_super_gitdir.buf, "worktree", "list",
+		    "--porcelain", NULL);
+
+	cp.git_cmd = 1;
+	if (capture_command(&cp, &out, 0) ||
+	    !string_list_split_in_place(&lines, out.buf, '\n', -1))
+		die("submodule.superprojectGitDir is stale; run 'git submodule "
+		    "update' from the superproject.");
+
+	for_each_string_list_item(it, &lines) {
+		char *trimmed;
+		/*
+		 * Lines containing worktree dirs look like
+		 * 'worktree /some/path'
+		 */
+		if (strncmp(it->string, wt_prefix, strlen(wt_prefix)))
+			continue;
+		trimmed = it->string + strlen(wt_prefix);
+
+		/*
+		 * '/some/path/to/sub' is a prefix of '/some/path' - that's our
+		 * worktree
+		 */
+		if (!strncmp(cwd, trimmed, strlen(trimmed))) {
+			strbuf_addstr(buf, trimmed);
+			rc = 1;
+			goto cleanup;
+		}
+	}
+
+fallback:
+	/*
+	 * Because a submodule may have been created before
+	 * submodule.superprojectGitDir was introduced, fall back on checking
+	 * whether ../ is the superproject.
+	 */
+	trace2_data_intmax("submodule", the_repository,
+			   "get_superproject_wt/config_missing", rc);
+	rc = get_superproject_working_tree_from_fs(buf);
+
+	/*
+	 * NEEDSWORK: Is it possible to teach a submodule the path to its
+	 * superproject when this happens?
+	 */
+
+cleanup:
+	string_list_clear(&lines, 0);
+	strbuf_release(&out);
+	return rc;
+}
+
 /*
  * Put the gitdir for a submodule (given relative to the main
  * repository worktree) into `buf`, or return -1 on error.
diff --git a/t/t1500-rev-parse.sh b/t/t1500-rev-parse.sh
index 1c2df08333..e569910289 100755
--- a/t/t1500-rev-parse.sh
+++ b/t/t1500-rev-parse.sh
@@ -247,6 +247,15 @@ test_expect_success 'showing the superproject correctly' '
 	test_cmp expect out
 '
 
+test_expect_success 'show the superproject correctly without superprojectGitDir' '
+	# repos created before submodule.superprojectGitDir was introduced which
+	# have not been `git submodule update`-ed lately must not break
+	git -C super/dir/sub config --unset submodule.superprojectGitDir &&
+	echo $(pwd)/super >expect &&
+	git -C super/dir/sub rev-parse --show-superproject-working-tree >out &&
+	test_cmp expect out
+'
+
 # at least one external project depends on this behavior:
 test_expect_success 'rev-parse --since= unsqueezed ordering' '
 	x1=--since=1970-01-01T00:00:01Z &&
-- 
2.34.0.rc1.387.gb447b232ab-goog


^ permalink raw reply	[flat|nested] 14+ messages in thread

* [RFC PATCH 0/2] submodule: test what happens if submodule.superprojectGitDir isn't around
  2021-11-17  0:56 [PATCH v6 0/5] teach submodules to know they're submodules Emily Shaffer
                   ` (4 preceding siblings ...)
  2021-11-17  0:57 ` [PATCH v6 5/5] submodule: use config to find superproject worktree Emily Shaffer
@ 2021-11-17 11:43 ` Ævar Arnfjörð Bjarmason
  2021-11-17 11:43   ` [RFC PATCH 1/2] submodule tests: fix potentially broken "config .. --unset" Ævar Arnfjörð Bjarmason
                     ` (2 more replies)
  2021-11-17 23:28 ` [PATCH v6 0/5] teach submodules to know they're submodules Jonathan Tan
  6 siblings, 3 replies; 14+ messages in thread
From: Ævar Arnfjörð Bjarmason @ 2021-11-17 11:43 UTC (permalink / raw)
  To: git
  Cc: Junio C Hamano, Emily Shaffer, Albert Cui, Phillip Wood,
	Johannes Schindelin, Matheus Tavares Bernardino, Jonathan Nieder,
	Jacob Keller, Atharva Raykar, Derrick Stolee, Jonathan Tan,
	Ævar Arnfjörð Bjarmason

On Tue, Nov 16 2021, Emily Shaffer wrote:

> [...]
> A couple things. Firstly, a semantics change *back* to the semantics of
> v3 - we map from gitdir to gitdir, *not* from common dir to common dir,
> so that theoretically a submodule with multiple worktrees in multiple
> superproject worktrees will be able to figure out which worktree of the
> superproject it's in. (Realistically, that's not really possible right
> now, but I'd like to change that soon.)
>
> Secondly, a rewording of comments and commit messages to indicate that
> this isn't a cache of some expensive operation, but rather intended to
> be the source of truth for all submodules. I also added a fifth commit
> rewriting `git rev-parse --show-superproject-working-tree` to
> demonstrate what that means in practice - but from a practical
> standpoint, I'm a little worried about that fifth patch. More details in
> the patch 5 description.
>
> I did discuss Ævar's idea of relying on in-process filesystem digging to
> find the superproject's gitdir with the rest of the Google team, but in
> the end decided that there are some worries about filesystem digging in
> this way (namely, some ugly interactions with network drives that are
> actually already an issue for Googler Linux machines). Plus, the allure
> of being able to definitively know that we're a submodule is pretty
> strong. ;) But overall, this is the direction I'd prefer to keep going                                                                                                                          
> in, rather than trying to guess from the filesystem going forward.

Did you try running the ad-hoc benchmark I included in [1] on that
Google NFS? I've dealt with some slow-ish network filesystems, but if
it's slower than AIX's local FS (where I couldn't see a difference) I'd
put money on it being a cross-Atlantic mount or something :)

Re your:

    "this isn't a cache of some expensive operation, but rather intended to                                                                                                                          be the source of truth for all submodules."

In your 5/5 it says, in seeming contradiction to this:

    This commit may be more of an RFC - to demonstrate what life looks like
    if we use submodule.superprojectGitDir as the source of truth. But since
    'git rev-parse --show-superproject-working-tree' is used in a lot of
    scripts in the wild[1], I'm not so sure it's a great example.

    To be honest, I'd prefer to die("Try running 'git submodule update'")
    here, but I don't think that's very script-friendly. However, falling
    back on the old implementation kind of undermines the idea of treating
    submodule.superprojectGitDir as the point of truth.

Most of what I've been suggesting in my [1] and related is that I'm
confused about if & how this is a pure caching mechanism.

Removing mentions of it being a cache but it seemingly still being a
cache at the tip of this series has just added to that confusion for
me :)

Anyway. While I do think this caching mechanism is probably
unnecessary in the short to medium term, i.e. it seems to the extent
that it was ever needed was due to some bridging of *.sh<->*.c that
we're *this* close to eliminating anyway.

But maybe I'm wrong. The benchmark I suggested above on that Google
NFS might be indicative. I don't really see how something that'll be
doing a bunch of FS ops anyway is going to be noticeably slower with
that approach, but maybe opening the index/tree of the superproject is
more expensive than I'm expecting.

In any case, all of that's not the hill I'm picking to die on. If
you'd like to go ahead with this cache-or-not-a-cache then sure, I
won't belabor that point.

I *do* strongly think if we're doing so though that we should have
something like this on top. I.e. let's test wha happens if we do and
don't have this "caching" variable, which is demonstrably easy to do.

Benchmarking the two gives me:

    $ git hyperfine -L rev HEAD~0 -L s true,false -s 'make -j8 all' '(cd t && GIT_TEST_SUBMODULE_CACHE_SUPERPROJECT_DIR={s} ./t7412-submodule-absorbgitdirs.sh)'
    Benchmark 1: (cd t && GIT_TEST_SUBMODULE_CACHE_SUPERPROJECT_DIR=true ./t7412-submodule-absorbgitdirs.sh)' in 'HEAD~0
      Time (mean ± σ):     545.9 ms ±   1.6 ms    [User: 490.3 ms, System: 114.0 ms]
      Range (min … max):   543.5 ms … 548.1 ms    10 runs
     
    Benchmark 2: (cd t && GIT_TEST_SUBMODULE_CACHE_SUPERPROJECT_DIR=false ./t7412-submodule-absorbgitdirs.sh)' in 'HEAD~0
      Time (mean ± σ):     537.9 ms ±  11.4 ms    [User: 476.8 ms, System: 117.6 ms]
      Range (min … max):   532.7 ms … 570.1 ms    10 runs
     
    Summary
      '(cd t && GIT_TEST_SUBMODULE_CACHE_SUPERPROJECT_DIR=false ./t7412-submodule-absorbgitdirs.sh)' in 'HEAD~0' ran
        1.01 ± 0.02 times faster than '(cd t && GIT_TEST_SUBMODULE_CACHE_SUPERPROJECT_DIR=true ./t7412-submodule-absorbgitdirs.sh)' in 'HEAD~0'

I.e. not using the cache is either indistinguishable or a bit faster
(the "a bit faster" is definitely due to just running less test code
though).

I'm sending this before the CI run[2] finishes (which now tests both
modes), but both of these work for me locally on a full test suite
run.

1. https://lore.kernel.org/git/211109.86v912dtfw.gmgdl@evledraar.gmail.com/
2. https://github.com/avar/git/runs/4237446991?check_suite_focus=true

Ævar Arnfjörð Bjarmason (2):
  submodule tests: fix potentially broken "config .. --unset"
  submodule: add test mode for checking absence of "superProjectGitDir"

 ci/run-build-and-tests.sh          |  1 +
 git-submodule.sh                   |  2 +-
 submodule.c                        |  7 +++++++
 t/lib-submodule-superproject.sh    | 24 ++++++++++++++++++++++++
 t/t7406-submodule-update.sh        | 13 ++++++-------
 t/t7412-submodule-absorbgitdirs.sh | 19 ++++++-------------
 6 files changed, 45 insertions(+), 21 deletions(-)
 create mode 100644 t/lib-submodule-superproject.sh

-- 
2.34.0.796.g2c87ed6146a


^ permalink raw reply	[flat|nested] 14+ messages in thread

* [RFC PATCH 1/2] submodule tests: fix potentially broken "config .. --unset"
  2021-11-17 11:43 ` [RFC PATCH 0/2] submodule: test what happens if submodule.superprojectGitDir isn't around Ævar Arnfjörð Bjarmason
@ 2021-11-17 11:43   ` Ævar Arnfjörð Bjarmason
  2021-11-17 11:43   ` [RFC PATCH 2/2] submodule: add test mode for checking absence of "superProjectGitDir" Ævar Arnfjörð Bjarmason
  2021-11-23 20:08   ` [RFC PATCH 0/2] submodule: test what happens if submodule.superprojectGitDir isn't around Emily Shaffer
  2 siblings, 0 replies; 14+ messages in thread
From: Ævar Arnfjörð Bjarmason @ 2021-11-17 11:43 UTC (permalink / raw)
  To: git
  Cc: Junio C Hamano, Emily Shaffer, Albert Cui, Phillip Wood,
	Johannes Schindelin, Matheus Tavares Bernardino, Jonathan Nieder,
	Jacob Keller, Atharva Raykar, Derrick Stolee, Jonathan Tan,
	Ævar Arnfjörð Bjarmason

These "config ... --unset" at the start must be guarded by something
like a test_might_fail, or we'll fail if a previous test didn't run,
e.g. due to the --run option.

Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
---
 t/t7406-submodule-update.sh | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/t/t7406-submodule-update.sh b/t/t7406-submodule-update.sh
index b42a339982b..01e1acaf300 100755
--- a/t/t7406-submodule-update.sh
+++ b/t/t7406-submodule-update.sh
@@ -1063,7 +1063,7 @@ test_expect_success 'submodule update --quiet passes quietness to fetch with a s
 
 test_expect_success 'submodule update adds superproject gitdir to older repos' '
 	(cd super &&
-	 git -C submodule config --unset submodule.superprojectGitdir &&
+	 test_might_fail git -C submodule config --unset submodule.superprojectGitdir &&
 	 git submodule update &&
 	 test-tool path-utils relative_path \
 		"$(git rev-parse --absolute-git-dir)" \
@@ -1075,7 +1075,7 @@ test_expect_success 'submodule update adds superproject gitdir to older repos' '
 
 test_expect_success 'submodule update uses config.worktree if applicable' '
 	(cd super &&
-	 git -C submodule config --unset submodule.superprojectGitDir &&
+	 test_might_fail git -C submodule config --unset submodule.superprojectGitDir &&
 	 git -C submodule config extensions.worktreeConfig true &&
 	 git submodule update &&
 	 test-tool path-utils relative_path \
-- 
2.34.0.796.g2c87ed6146a


^ permalink raw reply	[flat|nested] 14+ messages in thread

* [RFC PATCH 2/2] submodule: add test mode for checking absence of "superProjectGitDir"
  2021-11-17 11:43 ` [RFC PATCH 0/2] submodule: test what happens if submodule.superprojectGitDir isn't around Ævar Arnfjörð Bjarmason
  2021-11-17 11:43   ` [RFC PATCH 1/2] submodule tests: fix potentially broken "config .. --unset" Ævar Arnfjörð Bjarmason
@ 2021-11-17 11:43   ` Ævar Arnfjörð Bjarmason
  2021-11-23 20:08   ` [RFC PATCH 0/2] submodule: test what happens if submodule.superprojectGitDir isn't around Emily Shaffer
  2 siblings, 0 replies; 14+ messages in thread
From: Ævar Arnfjörð Bjarmason @ 2021-11-17 11:43 UTC (permalink / raw)
  To: git
  Cc: Junio C Hamano, Emily Shaffer, Albert Cui, Phillip Wood,
	Johannes Schindelin, Matheus Tavares Bernardino, Jonathan Nieder,
	Jacob Keller, Atharva Raykar, Derrick Stolee, Jonathan Tan,
	Ævar Arnfjörð Bjarmason

Add a GIT_TEST_SUBMODULE_CACHE_SUPERPROJECT_DIR=false test mode to
assert what happens if "submodule.superProjectGitDir" is absent or
missing, this checks if the "fallback" codepath in
get_superproject_working_tree() is equivalent to the config lookup.

Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
---
 ci/run-build-and-tests.sh          |  1 +
 git-submodule.sh                   |  2 +-
 submodule.c                        |  7 +++++++
 t/lib-submodule-superproject.sh    | 24 ++++++++++++++++++++++++
 t/t7406-submodule-update.sh        |  9 ++++-----
 t/t7412-submodule-absorbgitdirs.sh | 19 ++++++-------------
 6 files changed, 43 insertions(+), 19 deletions(-)
 create mode 100644 t/lib-submodule-superproject.sh

diff --git a/ci/run-build-and-tests.sh b/ci/run-build-and-tests.sh
index cc62616d806..5132a210057 100755
--- a/ci/run-build-and-tests.sh
+++ b/ci/run-build-and-tests.sh
@@ -33,6 +33,7 @@ linux-gcc)
 	export GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME=master
 	export GIT_TEST_WRITE_REV_INDEX=1
 	export GIT_TEST_CHECKOUT_WORKERS=2
+	export GIT_TEST_SUBMODULE_CACHE_SUPERPROJECT_DIR=false
 	make test
 	;;
 linux-clang)
diff --git a/git-submodule.sh b/git-submodule.sh
index 7c247bee7f6..2b423ee05bc 100755
--- a/git-submodule.sh
+++ b/git-submodule.sh
@@ -453,7 +453,7 @@ cmd_update()
 		# changed, unless it's a fresh clone. Write to worktree if
 		# applicable, and point to superproject's worktree gitdir if
 		# applicable.
-		if test -z "$just_cloned"
+		if test -z "$just_cloned" && test "$GIT_TEST_SUBMODULE_CACHE_SUPERPROJECT_DIR" != "false"
 		then
 			sm_gitdir="$(git -C "$sm_path" rev-parse --absolute-git-dir)"
 			relative_gitdir="$(git rev-parse --path-format=relative \
diff --git a/submodule.c b/submodule.c
index ad95cdda07d..f0411a320a8 100644
--- a/submodule.c
+++ b/submodule.c
@@ -2143,6 +2143,9 @@ static void relocate_single_git_dir_into_superproject(const char *path)
 	if (!git_configset_get_bool(&sub_cs, "extensions.worktreeConfig", &tmp))
 		strbuf_addstr(&config_path, ".worktree");
 
+	if (!git_env_bool("GIT_TEST_SUBMODULE_CACHE_SUPERPROJECT_DIR", 1))
+		goto fallback;
+
 	git_config_set_in_file(config_path.buf, "submodule.superprojectGitdir",
 			       relative_path(absolute_path(get_git_dir()),
 					     real_new_git_dir, &sb));
@@ -2150,6 +2153,8 @@ static void relocate_single_git_dir_into_superproject(const char *path)
 	git_configset_clear(&sub_cs);
 	strbuf_release(&config_path);
 	strbuf_release(&sb);
+
+fallback:
 	free(old_git_dir);
 	free(real_old_git_dir);
 	free(real_new_git_dir);
@@ -2332,6 +2337,8 @@ int get_superproject_working_tree(struct strbuf *buf)
 	const char *wt_prefix = "worktree ";
 	int rc = 0;
 
+	if (!git_env_bool("GIT_TEST_SUBMODULE_CACHE_SUPERPROJECT_DIR", 1))
+		goto fallback;
 
 	/* Do we know we have a superproject? */
 	if (git_config_get_string("submodule.superprojectgitdir", &super_gitdir))
diff --git a/t/lib-submodule-superproject.sh b/t/lib-submodule-superproject.sh
new file mode 100644
index 00000000000..4d49dd3782e
--- /dev/null
+++ b/t/lib-submodule-superproject.sh
@@ -0,0 +1,24 @@
+#!/bin/sh
+
+test_lazy_prereq SUBMODULE_CACHE_SUPERPROJECT_DIR '
+	test_bool_env GIT_TEST_SUBMODULE_CACHE_SUPERPROJECT_DIR true
+'
+
+test_cmp_submodule_superprojectgitdir () {
+	if ! test_have_prereq SUBMODULE_CACHE_SUPERPROJECT_DIR
+	then
+		return 0
+	fi
+
+	git -C "$1" config submodule.superprojectGitDir >actual &&
+	test_cmp expect actual
+}
+
+test_file_not_empty_superprojectgitdir () {
+	if ! test_have_prereq SUBMODULE_CACHE_SUPERPROJECT_DIR
+	then
+		return 0
+	fi
+
+	test_file_not_empty "$(git -C $1 rev-parse --absolute-git-dir)/$2"
+}
diff --git a/t/t7406-submodule-update.sh b/t/t7406-submodule-update.sh
index 01e1acaf300..f362f8d0ef0 100755
--- a/t/t7406-submodule-update.sh
+++ b/t/t7406-submodule-update.sh
@@ -13,6 +13,7 @@ GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME=main
 export GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME
 
 . ./test-lib.sh
+. "$TEST_DIRECTORY"/lib-submodule-superproject.sh
 
 
 compare_head()
@@ -1068,8 +1069,7 @@ test_expect_success 'submodule update adds superproject gitdir to older repos' '
 	 test-tool path-utils relative_path \
 		"$(git rev-parse --absolute-git-dir)" \
 		"$(git -C submodule rev-parse --absolute-git-dir)" >expect &&
-	 git -C submodule config submodule.superprojectGitdir >actual &&
-	 test_cmp expect actual
+	 test_cmp_submodule_superprojectgitdir submodule
 	)
 '
 
@@ -1081,10 +1081,9 @@ test_expect_success 'submodule update uses config.worktree if applicable' '
 	 test-tool path-utils relative_path \
 		"$(git rev-parse --absolute-git-dir)" \
 		"$(git -C submodule rev-parse --absolute-git-dir)" >expect &&
-	 git -C submodule config submodule.superprojectGitdir >actual &&
-	 test_cmp expect actual &&
+	 test_cmp_submodule_superprojectgitdir submodule &&
 
-	 test_file_not_empty "$(git -C submodule rev-parse --absolute-git-dir)/config.worktree"
+	 test_file_not_empty_superprojectgitdir submodule config.worktree
 	)
 '
 
diff --git a/t/t7412-submodule-absorbgitdirs.sh b/t/t7412-submodule-absorbgitdirs.sh
index 5753f902687..6faab7e56e9 100755
--- a/t/t7412-submodule-absorbgitdirs.sh
+++ b/t/t7412-submodule-absorbgitdirs.sh
@@ -7,6 +7,7 @@ directory into the superproject.
 '
 
 . ./test-lib.sh
+. "$TEST_DIRECTORY"/lib-submodule-superproject.sh
 
 test_expect_success 'setup a real submodule' '
 	git init sub1 &&
@@ -38,9 +39,7 @@ test_expect_success 'absorb the git dir' '
 
 	test-tool path-utils relative_path "$superproject_gitdir" \
 		"$submodule_gitdir" >expect &&
-	git -C sub1 config submodule.superprojectGitDir >actual &&
-
-	test_cmp expect actual
+	test_cmp_submodule_superprojectgitdir sub1
 '
 
 test_expect_success 'absorbing does not fail for deinitialized submodules' '
@@ -78,9 +77,7 @@ test_expect_success 'absorb the git dir in a nested submodule' '
 
 	test-tool path-utils relative_path "$sub1_gitdir" "$sub1_nested_gitdir" \
 		>expect &&
-	git -C sub1/nested config submodule.superprojectGitDir >actual &&
-
-	test_cmp expect actual
+	test_cmp_submodule_superprojectgitdir sub1
 '
 
 test_expect_success 're-setup nested submodule' '
@@ -170,9 +167,7 @@ test_expect_success 'absorbgitdirs works when called from a superproject worktre
 
 	test-tool path-utils relative_path "$superproject_gitdir" \
 		"$submodule_gitdir" >expect &&
-	git -C sub4 config submodule.superprojectGitDir >actual &&
-
-	test_cmp expect actual
+	test_cmp_submodule_superprojectgitdir sub4
 	)
 '
 
@@ -199,12 +194,10 @@ test_expect_success 'absorbgitdirs works with a submodule with worktree config'
 
 	test-tool path-utils relative_path "$superproject_gitdir" \
 		"$submodule_gitdir" >expect &&
-	git -C sub5 config submodule.superprojectGitDir >actual &&
-
-	test_cmp expect actual &&
+	test_cmp_submodule_superprojectgitdir sub5 &&
 
 	# make sure the config went into the submodule config.worktree
-	test_file_not_empty "$submodule_gitdir/config.worktree"
+	test_file_not_empty_superprojectgitdir sub5 config.worktree
 	)
 '
 
-- 
2.34.0.796.g2c87ed6146a


^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [PATCH v6 0/5] teach submodules to know they're submodules
  2021-11-17  0:56 [PATCH v6 0/5] teach submodules to know they're submodules Emily Shaffer
                   ` (5 preceding siblings ...)
  2021-11-17 11:43 ` [RFC PATCH 0/2] submodule: test what happens if submodule.superprojectGitDir isn't around Ævar Arnfjörð Bjarmason
@ 2021-11-17 23:28 ` Jonathan Tan
  2021-11-23 20:28   ` Emily Shaffer
  6 siblings, 1 reply; 14+ messages in thread
From: Jonathan Tan @ 2021-11-17 23:28 UTC (permalink / raw)
  To: emilyshaffer
  Cc: git, albertcui, phillip.wood123, Johannes.Schindelin, avarab,
	gitster, matheus.bernardino, jrnieder, jacob.keller, raykar.ath,
	stolee, jonathantanmy

Emily Shaffer <emilyshaffer@google.com> writes:
> For the original cover letter, see
> https://lore.kernel.org/git/20210611225428.1208973-1-emilyshaffer%40google.com.

Also for reference, v4 and v5 (as a reply to v4) can be found here:
https://lore.kernel.org/git/20211014203416.2802639-1-emilyshaffer@google.com/

> Since v5:
> 
> A couple things. Firstly, a semantics change *back* to the semantics of
> v3 - we map from gitdir to gitdir, *not* from common dir to common dir,
> so that theoretically a submodule with multiple worktrees in multiple
> superproject worktrees will be able to figure out which worktree of the
> superproject it's in. (Realistically, that's not really possible right
> now, but I'd like to change that soon.)

Makes sense. Also, thanks for the tests covering what happens when this
is run from worktrees.

> Secondly, a rewording of comments and commit messages to indicate that
> this isn't a cache of some expensive operation, but rather intended to
> be the source of truth for all submodules. I also added a fifth commit
> rewriting `git rev-parse --show-superproject-working-tree` to
> demonstrate what that means in practice - but from a practical
> standpoint, I'm a little worried about that fifth patch. More details in
> the patch 5 description.

OK - this is not the "this variable being missing is OK" idea that I had
[1], but we want to be able to depend on it to some extent. (And it is
not a cache either - we are not planning to perform an operation to
obtain the superproject gitdir if the cache is missing, but we are just
going to assume that there is no superproject.)

To that end, the 5th patch is misleading - it is behaving exactly like a
cache. I think it's better to drop it.

What would make sense to me (and seems to be in the spirit of this patch
set) is to describe this as something that Git commands can rely on to
determine if the current repo is a submodule, for performance reasons.
So maybe Git commands/parameters that directly reference the submodule
concept like "--show-superproject-working-tree" will work hard to find
the superproject (by searching the filesystem), but those that do not
(e.g. "git status") can make assumptions.

Making this variable a source of truth wouldn't work, I think, because
the source of truth is whether this repo appears in a .gitmodules file
(and that hasn't changed).

To this end, I'll comment on the changes I'd like to see on the
individual patches too.

[1] https://lore.kernel.org/git/20210727174650.2462099-1-jonathantanmy@google.com/

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [PATCH v6 2/5] introduce submodule.superprojectGitDir record
  2021-11-17  0:56 ` [PATCH v6 2/5] introduce submodule.superprojectGitDir record Emily Shaffer
@ 2021-11-17 23:43   ` Jonathan Tan
  0 siblings, 0 replies; 14+ messages in thread
From: Jonathan Tan @ 2021-11-17 23:43 UTC (permalink / raw)
  To: emilyshaffer; +Cc: git, gitster, Jonathan Tan

Emily Shaffer <emilyshaffer@google.com> writes:
> Teach submodules a reference to their superproject's gitdir. This allows
> us to A) know that we're running from a submodule, and B) have a
> shortcut to the superproject's vitals, for example, configs.

If we're going with my proposal [1], I think it's worth further
explaining the concept right at the beginning of the commit message:

  Teach submodules a config variable referencing their superproject's
  gitdir. Git commands may rely on this reference to determine if the
  current repo is a submodule to another repo: if this reference is
  absent, Git may assume that the current repo is not a submodule. In
  practice, commands and arguments that specifially reference the
  submodule relationship (like "rev-parse
  --show-superproject-working-tree") will still search the ancestor
  directory, but others (say, a "git status" that prints the submodule's
  status in relation to its superproject or a config option that lets
  the superproject and submodule share config) would not.

[1] https://lore.kernel.org/git/20211117232846.2596110-1-jonathantanmy@google.com/

> By using a relative path instead of an absolute path, we can move the
> superproject directory around on the filesystem without breaking the
> submodule's pointer. And by using the path from gitdir to gitdir, we can
> move the submodule within the superproject's tree structure without
> breaking the submodule's pointer, too. Finally, by pointing at the
> superproject's worktree gitdir (if it exists), we ensure that we can
> tell which worktree contains our submodule.

OK.

> Since this hint value is only introduced during new submodule creation
> via `git submodule add`, though, there is more work to do to allow the
> record to be created at other times.

This is not a hint anymore. I would reword as:

  This commit teaches "git submodule add" to add the aforementioned
  config variable. Subsequent commits will teach other commands to do
  so.

> Once this new config is reliably in place, we can use it to know
> definitively that we are working in a submodule, and to know which
> superproject we are a submodule of. This allows us to do some
> value-added behavior, like letting "git status" print additional info
> about the submodule's status in relation to its superproject, or like
> letting the superproject and submodule share an additional config file
> separate from either one's local config.

I folded this into the first paragraph above, so this would no longer
needed if you used my suggestion above.

> +submodule.superprojectGitDir::
> +	The relative path from the submodule's gitdir to its superproject's
> +	gitdir. When Git is run in a repository, it usually makes no
> +	difference whether this repository is standalone or a submodule, but if
> +	this configuration variable is present, additional behavior may be
> +	possible, such as "git status" printing additional information about
> +	this submodule's status with respect to its superproject. This config
> +	should only be present in projects which are submodules, but is not
> +	guaranteed to be present in every submodule, so only optional
> +	value-added behavior should be linked to it. It is set automatically
> +	during submodule creation.

If we're going to rely on the variable more, this needs to be updated.
Maybe:

  If this repository is a submodule, the relative path from this repo's
  gitdir to its superproject's gitdir. Git commands may rely on this
  reference to determine if the current repo is a submodule to another
  repo: if this reference is absent, Git may assume that the current
  repo is not a submodule (this does not make a difference to most Git
  commands). It is set automatically during ??

(and probably each subsequent patch will need to update the ??)

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [RFC PATCH 0/2] submodule: test what happens if submodule.superprojectGitDir isn't around
  2021-11-17 11:43 ` [RFC PATCH 0/2] submodule: test what happens if submodule.superprojectGitDir isn't around Ævar Arnfjörð Bjarmason
  2021-11-17 11:43   ` [RFC PATCH 1/2] submodule tests: fix potentially broken "config .. --unset" Ævar Arnfjörð Bjarmason
  2021-11-17 11:43   ` [RFC PATCH 2/2] submodule: add test mode for checking absence of "superProjectGitDir" Ævar Arnfjörð Bjarmason
@ 2021-11-23 20:08   ` Emily Shaffer
  2021-11-24  1:38     ` Ævar Arnfjörð Bjarmason
  2 siblings, 1 reply; 14+ messages in thread
From: Emily Shaffer @ 2021-11-23 20:08 UTC (permalink / raw)
  To: Ævar Arnfjörð Bjarmason
  Cc: git, Junio C Hamano, Albert Cui, Phillip Wood,
	Johannes Schindelin, Matheus Tavares Bernardino, Jonathan Nieder,
	Jacob Keller, Atharva Raykar, Derrick Stolee, Jonathan Tan

On Wed, Nov 17, 2021 at 12:43:38PM +0100, Ævar Arnfjörð Bjarmason wrote:
> 
> On Tue, Nov 16 2021, Emily Shaffer wrote:
> 
> > [...]
> > A couple things. Firstly, a semantics change *back* to the semantics of
> > v3 - we map from gitdir to gitdir, *not* from common dir to common dir,
> > so that theoretically a submodule with multiple worktrees in multiple
> > superproject worktrees will be able to figure out which worktree of the
> > superproject it's in. (Realistically, that's not really possible right
> > now, but I'd like to change that soon.)
> >
> > Secondly, a rewording of comments and commit messages to indicate that
> > this isn't a cache of some expensive operation, but rather intended to
> > be the source of truth for all submodules. I also added a fifth commit
> > rewriting `git rev-parse --show-superproject-working-tree` to
> > demonstrate what that means in practice - but from a practical
> > standpoint, I'm a little worried about that fifth patch. More details in
> > the patch 5 description.
> >
> > I did discuss Ævar's idea of relying on in-process filesystem digging to
> > find the superproject's gitdir with the rest of the Google team, but in
> > the end decided that there are some worries about filesystem digging in
> > this way (namely, some ugly interactions with network drives that are
> > actually already an issue for Googler Linux machines). Plus, the allure
> > of being able to definitively know that we're a submodule is pretty
> > strong. ;) But overall, this is the direction I'd prefer to keep going                                                                                                                          
> > in, rather than trying to guess from the filesystem going forward.
> 
> Did you try running the ad-hoc benchmark I included in [1] on that
> Google NFS? I've dealt with some slow-ish network filesystems, but if
> it's slower than AIX's local FS (where I couldn't see a difference) I'd
> put money on it being a cross-Atlantic mount or something :)
> 
> Re your:
> 
>     "this isn't a cache of some expensive operation, but rather intended to                                                                                                                          be the source of truth for all submodules."
> 
> In your 5/5 it says, in seeming contradiction to this:
> 
>     This commit may be more of an RFC - to demonstrate what life looks like
>     if we use submodule.superprojectGitDir as the source of truth. But since
>     'git rev-parse --show-superproject-working-tree' is used in a lot of
>     scripts in the wild[1], I'm not so sure it's a great example.
> 
>     To be honest, I'd prefer to die("Try running 'git submodule update'")
>     here, but I don't think that's very script-friendly. However, falling
>     back on the old implementation kind of undermines the idea of treating
>     submodule.superprojectGitDir as the point of truth.
> 
> Most of what I've been suggesting in my [1] and related is that I'm
> confused about if & how this is a pure caching mechanism.
> 
> Removing mentions of it being a cache but it seemingly still being a
> cache at the tip of this series has just added to that confusion for
> me :)

Yeah, I think this was a bad choice for me to include that patch. I was
really hopeful that I could show off "look, we don't need to ever hunt
in the FS above us", but for established repos, that's a bad idea
(because lots of people are already using this 'git rev-parse
--show-superproject-work-tree' thing in scripts, like I mentioned). So I
think it was a mistake to include it at all. Rather, I think it's
probably a better idea to treat that particular entry point as "legacy"
and implement other things using 'submodule.superprojectGitDir'
directly.

Because the patch 5 illustrates: "I'm saying that this new config isn't
a cache, but look, here's how I can treat it like a cache that might be
invalid and here's how I can fall back on a potentially expensive
operation anyways." I think I could have illustrated it a little better
with something like "here's a brand new 'git rev-parse
--show-superproject-gitdir'" which directly calls on the new config.

So, sorry about that.

> 
> Anyway. While I do think this caching mechanism is probably
> unnecessary in the short to medium term, i.e. it seems to the extent
> that it was ever needed was due to some bridging of *.sh<->*.c that
> we're *this* close to eliminating anyway.
> 
> But maybe I'm wrong. The benchmark I suggested above on that Google
> NFS might be indicative. I don't really see how something that'll be
> doing a bunch of FS ops anyway is going to be noticeably slower with
> that approach, but maybe opening the index/tree of the superproject is
> more expensive than I'm expecting.
> 
> In any case, all of that's not the hill I'm picking to die on. If
> you'd like to go ahead with this cache-or-not-a-cache then sure, I
> won't belabor that point.

Yeah, I think I would. I've heard some serious reservations from others
on my team about trying to use filesystem traversal here at all, so I
think that would be an uphill battle.

> 
> I *do* strongly think if we're doing so though that we should have
> something like this on top. I.e. let's test wha happens if we do and
> don't have this "caching" variable, which is demonstrably easy to do.
> 
> Benchmarking the two gives me:
> 
>     $ git hyperfine -L rev HEAD~0 -L s true,false -s 'make -j8 all' '(cd t && GIT_TEST_SUBMODULE_CACHE_SUPERPROJECT_DIR={s} ./t7412-submodule-absorbgitdirs.sh)'
>     Benchmark 1: (cd t && GIT_TEST_SUBMODULE_CACHE_SUPERPROJECT_DIR=true ./t7412-submodule-absorbgitdirs.sh)' in 'HEAD~0
>       Time (mean ± σ):     545.9 ms ±   1.6 ms    [User: 490.3 ms, System: 114.0 ms]
>       Range (min … max):   543.5 ms … 548.1 ms    10 runs
>      
>     Benchmark 2: (cd t && GIT_TEST_SUBMODULE_CACHE_SUPERPROJECT_DIR=false ./t7412-submodule-absorbgitdirs.sh)' in 'HEAD~0
>       Time (mean ± σ):     537.9 ms ±  11.4 ms    [User: 476.8 ms, System: 117.6 ms]
>       Range (min … max):   532.7 ms … 570.1 ms    10 runs
>      
>     Summary
>       '(cd t && GIT_TEST_SUBMODULE_CACHE_SUPERPROJECT_DIR=false ./t7412-submodule-absorbgitdirs.sh)' in 'HEAD~0' ran
>         1.01 ± 0.02 times faster than '(cd t && GIT_TEST_SUBMODULE_CACHE_SUPERPROJECT_DIR=true ./t7412-submodule-absorbgitdirs.sh)' in 'HEAD~0'
> 
> I.e. not using the cache is either indistinguishable or a bit faster
> (the "a bit faster" is definitely due to just running less test code
> though).

Yeah, once again, I think it is better to treat "git rev-parse
--show-superproject-work-tree" as "legacy" and to rely solely on the
config for new options, meaning that "what happens without this
variable" is as simple as "we treat it like it's a standalone repository
with no superproject", rather than a performance difference at all.

 - Emily

> 
> I'm sending this before the CI run[2] finishes (which now tests both
> modes), but both of these work for me locally on a full test suite
> run.
> 
> 1. https://lore.kernel.org/git/211109.86v912dtfw.gmgdl@evledraar.gmail.com/
> 2. https://github.com/avar/git/runs/4237446991?check_suite_focus=true
> 
> Ævar Arnfjörð Bjarmason (2):
>   submodule tests: fix potentially broken "config .. --unset"
>   submodule: add test mode for checking absence of "superProjectGitDir"
> 
>  ci/run-build-and-tests.sh          |  1 +
>  git-submodule.sh                   |  2 +-
>  submodule.c                        |  7 +++++++
>  t/lib-submodule-superproject.sh    | 24 ++++++++++++++++++++++++
>  t/t7406-submodule-update.sh        | 13 ++++++-------
>  t/t7412-submodule-absorbgitdirs.sh | 19 ++++++-------------
>  6 files changed, 45 insertions(+), 21 deletions(-)
>  create mode 100644 t/lib-submodule-superproject.sh
> 
> -- 
> 2.34.0.796.g2c87ed6146a
> 

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [PATCH v6 0/5] teach submodules to know they're submodules
  2021-11-17 23:28 ` [PATCH v6 0/5] teach submodules to know they're submodules Jonathan Tan
@ 2021-11-23 20:28   ` Emily Shaffer
  0 siblings, 0 replies; 14+ messages in thread
From: Emily Shaffer @ 2021-11-23 20:28 UTC (permalink / raw)
  To: Jonathan Tan
  Cc: git, albertcui, phillip.wood123, Johannes.Schindelin, avarab,
	gitster, matheus.bernardino, jrnieder, jacob.keller, raykar.ath,
	stolee

On Wed, Nov 17, 2021 at 03:28:46PM -0800, Jonathan Tan wrote:
> 
> Emily Shaffer <emilyshaffer@google.com> writes:
> > For the original cover letter, see
> > https://lore.kernel.org/git/20210611225428.1208973-1-emilyshaffer%40google.com.
> 
> Also for reference, v4 and v5 (as a reply to v4) can be found here:
> https://lore.kernel.org/git/20211014203416.2802639-1-emilyshaffer@google.com/
> 
> > Since v5:
> > 
> > A couple things. Firstly, a semantics change *back* to the semantics of
> > v3 - we map from gitdir to gitdir, *not* from common dir to common dir,
> > so that theoretically a submodule with multiple worktrees in multiple
> > superproject worktrees will be able to figure out which worktree of the
> > superproject it's in. (Realistically, that's not really possible right
> > now, but I'd like to change that soon.)
> 
> Makes sense. Also, thanks for the tests covering what happens when this
> is run from worktrees.
> 
> > Secondly, a rewording of comments and commit messages to indicate that
> > this isn't a cache of some expensive operation, but rather intended to
> > be the source of truth for all submodules. I also added a fifth commit
> > rewriting `git rev-parse --show-superproject-working-tree` to
> > demonstrate what that means in practice - but from a practical
> > standpoint, I'm a little worried about that fifth patch. More details in
> > the patch 5 description.
> 
> OK - this is not the "this variable being missing is OK" idea that I had
> [1], but we want to be able to depend on it to some extent. (And it is
> not a cache either - we are not planning to perform an operation to
> obtain the superproject gitdir if the cache is missing, but we are just
> going to assume that there is no superproject.)
> 
> To that end, the 5th patch is misleading - it is behaving exactly like a
> cache. I think it's better to drop it.

Yeah, I think you are right.

> 
> What would make sense to me (and seems to be in the spirit of this patch
> set) is to describe this as something that Git commands can rely on to
> determine if the current repo is a submodule, for performance reasons.
> So maybe Git commands/parameters that directly reference the submodule
> concept like "--show-superproject-working-tree" will work hard to find
> the superproject (by searching the filesystem), but those that do not
> (e.g. "git status") can make assumptions.

Oh interesting, I like the idea of that distinction. Thanks for the
suggestion.

I wonder, though, how best to delineate. I'd almost rather say like I
suggested to Ævar
(https://lore.kernel.org/git/YZ1KLNwsxx7IR1%2B5%40google.com), that we
can treat "--show-superproject-working-tree" as a "legacy" option people
are already using, and treat anything added from now on as "if it
doesn't think it is a submodule, you should 'git submodule update' in
the superproject". That relies on us being able to reliably keep the
value of submodule.superprojectGitDir correct, but I think the
gitdir->gitdir linking helps with that (as opposed to earlier
iterations).
> 
> Making this variable a source of truth wouldn't work, I think, because
> the source of truth is whether this repo appears in a .gitmodules file
> (and that hasn't changed).

Interestingly, '--show-superproject-working-tree' doesn't check the
.gitmodules file at all. It checks whether the project found in the
filesystem above it knows about an object named path/to/superproject/
which is a gitlink - that is, it asks the index, not .gitmodules, as far
as I understand it. So if the only existing alternative to
submodule.superprojectGitDir isn't treating .gitmodules as source of
truth, then what does that mean?

> 
> To this end, I'll comment on the changes I'd like to see on the
> individual patches too.
> 
> [1] https://lore.kernel.org/git/20210727174650.2462099-1-jonathantanmy@google.com/

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [RFC PATCH 0/2] submodule: test what happens if submodule.superprojectGitDir isn't around
  2021-11-23 20:08   ` [RFC PATCH 0/2] submodule: test what happens if submodule.superprojectGitDir isn't around Emily Shaffer
@ 2021-11-24  1:38     ` Ævar Arnfjörð Bjarmason
  0 siblings, 0 replies; 14+ messages in thread
From: Ævar Arnfjörð Bjarmason @ 2021-11-24  1:38 UTC (permalink / raw)
  To: Emily Shaffer
  Cc: git, Junio C Hamano, Albert Cui, Phillip Wood,
	Johannes Schindelin, Matheus Tavares Bernardino, Jonathan Nieder,
	Jacob Keller, Atharva Raykar, Derrick Stolee, Jonathan Tan


On Tue, Nov 23 2021, Emily Shaffer wrote:

> On Wed, Nov 17, 2021 at 12:43:38PM +0100, Ævar Arnfjörð Bjarmason wrote:
>> 
>> On Tue, Nov 16 2021, Emily Shaffer wrote:
>> 
>> > [...]
>> > A couple things. Firstly, a semantics change *back* to the semantics of
>> > v3 - we map from gitdir to gitdir, *not* from common dir to common dir,
>> > so that theoretically a submodule with multiple worktrees in multiple
>> > superproject worktrees will be able to figure out which worktree of the
>> > superproject it's in. (Realistically, that's not really possible right
>> > now, but I'd like to change that soon.)
>> >
>> > Secondly, a rewording of comments and commit messages to indicate that
>> > this isn't a cache of some expensive operation, but rather intended to
>> > be the source of truth for all submodules. I also added a fifth commit
>> > rewriting `git rev-parse --show-superproject-working-tree` to
>> > demonstrate what that means in practice - but from a practical
>> > standpoint, I'm a little worried about that fifth patch. More details in
>> > the patch 5 description.
>> >
>> > I did discuss Ævar's idea of relying on in-process filesystem digging to
>> > find the superproject's gitdir with the rest of the Google team, but in
>> > the end decided that there are some worries about filesystem digging in
>> > this way (namely, some ugly interactions with network drives that are
>> > actually already an issue for Googler Linux machines). Plus, the allure
>> > of being able to definitively know that we're a submodule is pretty
>> > strong. ;) But overall, this is the direction I'd prefer to keep
>> > going
>> > in, rather than trying to guess from the filesystem going forward.
>> 
>> Did you try running the ad-hoc benchmark I included in [1] on that
>> Google NFS? I've dealt with some slow-ish network filesystems, but if
>> it's slower than AIX's local FS (where I couldn't see a difference) I'd
>> put money on it being a cross-Atlantic mount or something :)
>> 
>> Re your:
>> 
>>     "this isn't a cache of some expensive operation, but rather
>> intended to be the source of truth for all submodules."
>> 
>> In your 5/5 it says, in seeming contradiction to this:
>> 
>>     This commit may be more of an RFC - to demonstrate what life looks like
>>     if we use submodule.superprojectGitDir as the source of truth. But since
>>     'git rev-parse --show-superproject-working-tree' is used in a lot of
>>     scripts in the wild[1], I'm not so sure it's a great example.
>> 
>>     To be honest, I'd prefer to die("Try running 'git submodule update'")
>>     here, but I don't think that's very script-friendly. However, falling
>>     back on the old implementation kind of undermines the idea of treating
>>     submodule.superprojectGitDir as the point of truth.
>> 
>> Most of what I've been suggesting in my [1] and related is that I'm
>> confused about if & how this is a pure caching mechanism.
>> 
>> Removing mentions of it being a cache but it seemingly still being a
>> cache at the tip of this series has just added to that confusion for
>> me :)
>
> Yeah, I think this was a bad choice for me to include that patch. I was
> really hopeful that I could show off "look, we don't need to ever hunt
> in the FS above us", but for established repos, that's a bad idea
> (because lots of people are already using this 'git rev-parse
> --show-superproject-work-tree' thing in scripts, like I mentioned). So I
> think it was a mistake to include it at all. Rather, I think it's
> probably a better idea to treat that particular entry point as "legacy"
> and implement other things using 'submodule.superprojectGitDir'
> directly.
>
> Because the patch 5 illustrates: "I'm saying that this new config isn't
> a cache, but look, here's how I can treat it like a cache that might be
> invalid and here's how I can fall back on a potentially expensive
> operation anyways." I think I could have illustrated it a little better
> with something like "here's a brand new 'git rev-parse
> --show-superproject-gitdir'" which directly calls on the new config.
>
> So, sorry about that.

The RFC series here shows that the config & the on-the-fly discovery 1=1
map to each other (at least in terms of the tests your series adds).

Why wouldn't the same be the case with a --show-superproject-gitdir?
Unless the fallback implementation was intentionally removed.

>> 
>> Anyway. While I do think this caching mechanism is probably
>> unnecessary in the short to medium term, i.e. it seems to the extent
>> that it was ever needed was due to some bridging of *.sh<->*.c that
>> we're *this* close to eliminating anyway.
>> 
>> But maybe I'm wrong. The benchmark I suggested above on that Google
>> NFS might be indicative. I don't really see how something that'll be
>> doing a bunch of FS ops anyway is going to be noticeably slower with
>> that approach, but maybe opening the index/tree of the superproject is
>> more expensive than I'm expecting.
>> 
>> In any case, all of that's not the hill I'm picking to die on. If
>> you'd like to go ahead with this cache-or-not-a-cache then sure, I
>> won't belabor that point.
>
> Yeah, I think I would. I've heard some serious reservations from others
> on my team about trying to use filesystem traversal here at all, so I
> think that would be an uphill battle.

Do they have any benchmarks to share? :)

>> 
>> I *do* strongly think if we're doing so though that we should have
>> something like this on top. I.e. let's test wha happens if we do and
>> don't have this "caching" variable, which is demonstrably easy to do.
>> 
>> Benchmarking the two gives me:
>> 
>>     $ git hyperfine -L rev HEAD~0 -L s true,false -s 'make -j8 all' '(cd t && GIT_TEST_SUBMODULE_CACHE_SUPERPROJECT_DIR={s} ./t7412-submodule-absorbgitdirs.sh)'
>>     Benchmark 1: (cd t && GIT_TEST_SUBMODULE_CACHE_SUPERPROJECT_DIR=true ./t7412-submodule-absorbgitdirs.sh)' in 'HEAD~0
>>       Time (mean ± σ):     545.9 ms ±   1.6 ms    [User: 490.3 ms, System: 114.0 ms]
>>       Range (min … max):   543.5 ms … 548.1 ms    10 runs
>>      
>>     Benchmark 2: (cd t && GIT_TEST_SUBMODULE_CACHE_SUPERPROJECT_DIR=false ./t7412-submodule-absorbgitdirs.sh)' in 'HEAD~0
>>       Time (mean ± σ):     537.9 ms ±  11.4 ms    [User: 476.8 ms, System: 117.6 ms]
>>       Range (min … max):   532.7 ms … 570.1 ms    10 runs
>>      
>>     Summary
>>       '(cd t && GIT_TEST_SUBMODULE_CACHE_SUPERPROJECT_DIR=false ./t7412-submodule-absorbgitdirs.sh)' in 'HEAD~0' ran
>>         1.01 ± 0.02 times faster than '(cd t && GIT_TEST_SUBMODULE_CACHE_SUPERPROJECT_DIR=true ./t7412-submodule-absorbgitdirs.sh)' in 'HEAD~0'
>> 
>> I.e. not using the cache is either indistinguishable or a bit faster
>> (the "a bit faster" is definitely due to just running less test code
>> though).
>
> Yeah, once again, I think it is better to treat "git rev-parse
> --show-superproject-work-tree" as "legacy" and to rely solely on the
> config for new options, meaning that "what happens without this
> variable" is as simple as "we treat it like it's a standalone repository
> with no superproject", rather than a performance difference at all.

Why would it be better to have a hard reliance on the config for new
features or options? Your original CL says[1]:

    It's expensive and non-definitive to try and guess whether or not the
    current repo is a submodule.

Maybe that's the case somewhere, I haven't been able to dig up the
"expensive" part (aside from the fixable case of exec-ing rev-parse in a
loop).

Which leaves "non-definitive", that may be the case, but as the RFC
patches here show if there is such a case, it's not covered by any of
your existing tests in this series.

I'd think if those two things hold true (not expensive, and we can
unambiguously discover it on the fly) our bias should be towards not
introducing an indirection in the config, as such a thing needs to be
kept up-to-date, and which may become inaccurate for whatever
reason. Whereas the FS relationship between the won't ever be
out-of-date.

1. https://lore.kernel.org/git/20210611225428.1208973-1-emilyshaffer@google.com

^ permalink raw reply	[flat|nested] 14+ messages in thread

end of thread, other threads:[~2021-11-24  1:52 UTC | newest]

Thread overview: 14+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-11-17  0:56 [PATCH v6 0/5] teach submodules to know they're submodules Emily Shaffer
2021-11-17  0:56 ` [PATCH v6 1/5] t7400-submodule-basic: modernize inspect() helper Emily Shaffer
2021-11-17  0:56 ` [PATCH v6 2/5] introduce submodule.superprojectGitDir record Emily Shaffer
2021-11-17 23:43   ` Jonathan Tan
2021-11-17  0:56 ` [PATCH v6 3/5] submodule: record superproject gitdir during absorbgitdirs Emily Shaffer
2021-11-17  0:57 ` [PATCH v6 4/5] submodule: record superproject gitdir during 'update' Emily Shaffer
2021-11-17  0:57 ` [PATCH v6 5/5] submodule: use config to find superproject worktree Emily Shaffer
2021-11-17 11:43 ` [RFC PATCH 0/2] submodule: test what happens if submodule.superprojectGitDir isn't around Ævar Arnfjörð Bjarmason
2021-11-17 11:43   ` [RFC PATCH 1/2] submodule tests: fix potentially broken "config .. --unset" Ævar Arnfjörð Bjarmason
2021-11-17 11:43   ` [RFC PATCH 2/2] submodule: add test mode for checking absence of "superProjectGitDir" Ævar Arnfjörð Bjarmason
2021-11-23 20:08   ` [RFC PATCH 0/2] submodule: test what happens if submodule.superprojectGitDir isn't around Emily Shaffer
2021-11-24  1:38     ` Ævar Arnfjörð Bjarmason
2021-11-17 23:28 ` [PATCH v6 0/5] teach submodules to know they're submodules Jonathan Tan
2021-11-23 20:28   ` Emily Shaffer

Code repositories for project(s) associated with this inbox:

	https://80x24.org/mirrors/git.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).