Jonathan Nieder <jrnieder@xxxxxxxxx> writes: > My point with this example is that it's useful to have a definition of > what is a submodule repository, to make it unambiguous whether this > repository is a submodule or whether it's just a repository that > happens to have been cloned inside of a git-managed worktree. OK, together with the other "no need to let NFS automounter worry about parent directories", it makes a very successful argument for a single bit (i.e. this is a free-standing repository and is not a submodule, so no need to auto-discover if it is one). I think the "Alternatively" you later mention to solve ambiguity with just a single bit, without "this is a submodule of that superproject" linkage, is essentially the same? But I do not think it argues for the need to say "a config, not filesystem layout, must be the single source of truth to say which superproject this repository belongs as its submodule". > This would be the first time in git history that we are saying a > property of a repository depends on having to examine files outside of > it. Well, path-based configuration inclusion, with configuration driven hooks, I do not think the distinction matters much anymore in these days. > I guess the main question I'd have is, why _wouldn't_ I want a > submodule to be able to point to the superproject containing it? Because with (the absense of) a single "this is freestanding" bit, by default the filesystem layout can already "point" at it?
