On Tue, Feb 08, 2022 at 10:24:49AM -0800, Junio C Hamano wrote: > > 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? That resolution - "teach submodules to know they're submodules, but not whose submodule they are" - would still count as a success to me. The reason I proposed a path instead of a boolean here was simply because storing a path is a boolean (by whether it's present or not) *and* additional information (the path to the superproject), and it seemed silly to me to opt for less information. Or, to put it another way - "am I a submodule?" seems pretty vital, and "yes, and I belong to xyz" is an optimization on top of that. So I don't terribly mind sending this as just a boolean, if we feel that the effort to keep it up outweighs the benefit of saving us a filesystem walk. I'm not completely convinced that it does, though - would the addition of a 'git fsck' check for this config be satisfactory? In other words, is the problem that the execution of this series wasn't thorough enough and it should be refined, or that the concept itself is beyond saving? - Emily > > 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?
