Re: [PATCH v6 0/5] teach submodules to know they're submodules

Emily Shaffer [off-list ref] writes:

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.)

Sounds sensible.

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'd expect that there is a way (e.g. "git fsck") that helps the
users notice when the actual filesystem layout contradicts with what
the gitdir-to-gitdir link says, and repair the repositories when
they go out of sync if possible.

It would be similar to "git worktree", where a link between the
".git" file that records "gitdir:" in a secondary worktree and the
repository's $GIT_DIR/worktrees/*/gitdir, and the "repair" command
can be used to bring them back in sync after moving the real
repository without telling the secondary worktree about the move.

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.

The other side of the coin is that, even when a configuration
variable says that you are a submodule of the superproject at
location X, if such a submodule gets moved out of the superproject
(perhaps because the end-user wanted to concentrate on that
submodule project alone as an independent project) and the
superproject that used to be at location X got archived away,
trusting and relying on what the configuration variable says would
not help us access the now-gone superproject.  And that would not
change no matter how strongly we declare that it is the source of
truth.

Unless we have a very good way to detect inconsistency and stop
spreading the damage (e.g. the setting thought our superproject sits
at directory X, but that location is now occupied by a different
repository that is not related), I am still skeptical about the
"setting is the sole truth" design.