On Sun, Oct 19, 2014 at 09:30:15PM +0200, Jens Lehmann wrote: > Am 16.10.2014 um 22:54 schrieb Max Kirillov: >> On Wed, Oct 15, 2014 at 08:57:20PM +0200, Jens Lehmann wrote: >>> Am 15.10.2014 um 00:15 schrieb Max Kirillov: >>>> I think the logic can be simple: it a submodule is not >>>> checked-out in the repository "checkout --to" is called >>>> from, then it is not checked-out to the new one also. If it >>>> is, then checkout calls itself recursively in the submodule >>>> and works like being run in standalone repository.
>>> But when I later decide to populate the submodule in a >>> "checkout --to" work tree, should it automagically also >>> use the central storage, creating the modules/<name> >>> directory there if it doesn't exist yet? I think that'd >>> make sense to avoid having the work tree layout depend >>> on the order commands were ran in. And imagine new >>> submodules, they should not be handled differently from >>> those already present. >> Like place the common directory to >> $MAIN_REPO/.git/modules/$SUB/ and worktree-specific part to >> $MAIN_REPO/.git/worktrees/$WORKTREE/modules/$SUB, rather >> than placing all into the socond one? It would make sense to >> make, but then it would be imposible to checkout a diferent >> repository into the same submodule in different superproject >> checkouts. However stupid is sounds, there could be cases >> if, for example, at some moment submodule is being replaced >> by another one, and older worktrees should work with older >> submodule, while newer uses the newer submodule. > Yes, but I believe that the user must be careful to not > reuse the same submodule name for a different repo anyways, > no matter if shared or not. Currently you'll get a warning > about that when trying to add a submodule whose name is > already found in .git/modules to avoid such confusion. Yes, while trying to write tests for this case I discovered that there are warnings and the recommended way is to use different names for different repositories even if they are pointing to the same path. Then always placing common directory into the .git/modules/<module> could be a good idea, and in very special cases users could manually create repositories with custom placement. >> Also, could you clarify the usage of the /modules/ >> directory. I did not notice it to affect anything after the >> submofule is placed there. Submodule operations use the >> submodule repositories directly (through the git link, which >> can point anywhere), or in .gitmodules file, or maybe in >> .git/config. So there is actually no need to have that >> gitdir there. Is it correct? > Nope. When submodules are cloned their git directory is > placed under .git/modules/<submodule name>, the .git file > in the work tree points there and the core.worktree setting > points back from there to the work tree. I meant is the fact that gitdir is placed in modules, rather than in any other place, is used anywhere. There are 2 places to put the gitdir of submodule in linked copy: 1. $MAIN_REPO/.git/worktrees/$WORKTREE/modules/$SUB 2. $MAIN_REPO/.git/modules/$SUB/worktrees/$SUB_WTNAME First one is suggested by submodule way of placing gitdirs, and the second one by worrktree way. There are reasons to have the second one - garbage collection and check that 2 branch is not checked out twice. Are there resons to have the 1st one? The one is to prevent use of different repositories with the same name, anything else? -- Max -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
