On Fri, Nov 05, 2021 at 12:50:22AM -0700, Junio C Hamano wrote: > > Emily Shaffer <emilyshaffer@xxxxxxxxxx> writes: > > > 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 > > move the submodule within the superproject's tree structure without > > breaking the submodule's cache, too. > > All of the above explains what the design choice is, and what > benefit the chosen design brings us. But this last one ... > > > 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. > > ... only says that we choose to point at the common one, not a > specific worktree (i.e. what behaviour was chosen by the design), > but it is left unclear what benefit it is trying to bring us. > > Thinking aloud, imagine that there are two worktrees for the > superproject. For simplicity, let's further imagine that these > worktrees have a clean check-out of the same commit, hence, these > two worktrees have the same commit from the same submodule checked > out at the same location relative to the project root. > > The subdirectory in each of these two superproject worktrees that > checks out the submodule has .git file (as we "absorb" the gitdir in > the modern submodule layout) pointing at somewhere. It probably is > OK if they point at the same place, but it might be more natural if > these two submodule checkouts are two worktrees for a single > submodule repository (this part I am not very clear, and that is why > I labeled the discussion "thinking aloud"). > > It seems to me that both design choices would have equally valid > arguments for them. If both of these submodule worktrees point at > the "common" dir of the superproject, because the "common" one is > part of the primary worktree, which is harder to lose than secondary > worktrees, of the superproject, it is presumably harder to go stale > when "worktree rm" is done at superproject, which may be a plus. > But then from the "cached" pointer, each of these submodule > worktrees cannot tell which worktree of the superproject they are > checked out as a part of. Of course we can go to the root level of > the submodule worktree and do the usual repository discovery to > learn where the root level of the superproject worktree it belongs > to, but it somehow feels that it defeats half the point of having > this "cache" information. > > If we instead point at the git-dir, from there, it is just one level > of indirection to find out where the common dir of the superproject > is. > > > 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. > > And one value-add that I would think of off the top of my head is to > show "we have commit X checked out, which is 4 commits on top of > what the superproject's index records for this submodule" when "git > status" is run in the submodule's worktree. I do not know that is > an operation to specifically optimize for, but by choosing to > "cache" the common dir, not the one specific to the worktree of the > superporject our submodule checkout is a part of, the chosen design > seems to make it harder to implement? Yeah, that is compelling. Sorry not to reply in depth, but I am convinced. - Emily
