On Fri, Apr 09, 2021 at 03:29:46PM -0700, Junio C Hamano wrote: > > Matheus Tavares Bernardino <matheus.bernardino@xxxxxx> writes: > > > Hi, Emily > > > > I'm not familiar enough with this code to give a full review and I > > imagine you probably want comments more focused on the design level, > > while this is an RFC, but here are some small nitpicks I found while > > reading the patch. I Hope it helps :) > > > > On Thu, Apr 8, 2021 at 8:39 PM Emily Shaffer <emilyshaffer@xxxxxxxxxx> wrote: > >> > >> diff --git a/Documentation/git-config.txt b/Documentation/git-config.txt > >> index 4b4cc5c5e8..a33136fb08 100644 > >> --- a/Documentation/git-config.txt > >> +++ b/Documentation/git-config.txt > >> @@ -48,7 +48,7 @@ unset an existing `--type` specifier with `--no-type`. > >> > >> When reading, the values are read from the system, global and > >> repository local configuration files by default, and options > >> -`--system`, `--global`, `--local`, `--worktree` and > >> +`--system`, `--global`, `--superproject`, `--local`, `--worktree` and > >> `--file <filename>` can be used to tell the command to read from only > >> that location (see <<FILES>>). > >> > >> @@ -127,6 +127,17 @@ rather than from all available files. > >> + > >> See also <<FILES>>. > >> > >> +--superproject:: > >> + For writing options: write to the superproject's > >> + `.git/config.superproject` file, even if run from a submodule of that > >> + superproject. > > > > Hmm, I wonder what happens if a repo is both a submodule and a > > superproject (i.e. in case of nested submodules). > > Another thing I am not sure about the design is that a repository > can be shared as a submodule by more than one superprojects. The > superprojects may want their submodule checkouts at different > submodule commits, but that is something doable by having multiple > worktrees connected to a single submodule repository. I think the implementation as-written actually handles this sharing-via-worktree case you describe gracefully, as it discovers the gitdir belonging to the worktree above the worktree where it is being run now: superproject-a -> sub-a <gitdir at superproject-a/.git/modules/sub-a/> superproject-b -> sub-b <gitdir at superproject-a/.git/modules/sub-a/worktrees/sub-b/> In this case running `git config --list --superproject` in sub-a will yield superproject-a/.git/config.superproject and running it in sub-b will yield superproject-b/.git/config.superproject; that seems logical to me. If I am adding libc as a submodule via worktree to Git as well as, say, Wireshark, just to save me on disk space, I wouldn't want my Wireshark hooks to run in Git project or vice versa. > I think our design principle has been that it is perfectly OK for a > superproject to be in total control if its submodules, but > submodules should not even be aware of being used as a submodule by > a superproject, and that allows a submodule repository to be shared > by multiple superprojects. As "write to the superproject's X file" > requires a submodule to know who THE superproject of itself is, this > feature itself (not the implementation) feels somewhat iffy. As for this, I wonder what the reasoning is. I guess to simplify the code, and to make the behavior more predictable (for example, 'git commit' doesn't suddenly make a commit in some project that isn't this one)? One could imagine some really nice quality-of-life improvements if the submodule is allowed to know it's a submodule (even by a config, for example): - We could teach 'git status' to indicate the state when the submodule index is clean, but the superproject does not contain a commit pointing to the submodule's HEAD - which could still be considered a dirty state, since the change isn't associated with the larger project yet. I could imagine there might be other handy information related to submodule/superproject status we may want to display too. - We could teach 'git log' to decorate commits which are referred to by superproject commits, perhaps? - We could teach 'git push' to, by option or config, push the entire superproject-and-submodules package at once, to make it easier to coordinate changes across the whole superproject - One could envision some other niceties like 'git stash --whole-superproject' or similar, where a user could operate on the entire overall project (that is, the superproject and all its submodules) without needing to switch context away I don't think lacking these things would stop a user from doing something they want to do, but it does seem like they could make life more comfortable for a user developing in a project made up of many submodules. - Emily
