Re: [PATCH 0/4] Multiple worktrees vs. submodules fixes

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Am 03.11.2014 um 13:54 schrieb Duy Nguyen:
Ping.. any idea how to go from here..

I didn't dig deep enough into the multiple worktrees topic to
know what "$MAIN_REPO/.git/worktrees/$WORKTREE/modules/$SUB"
might mean, but a submodule whose repo lives under
.git/modules/$SUBMODULE_NAME should have its worktree in
$SUBMODULE_PATH of the superproject's worktree.

So if we share submodule repos, the sharable stuff should
live under $MAIN_REPO/.git/modules/$SUBMODULE_NAME/. But
everything that can't be put there should stay under the
.git/modules/$SUBMODULE_NAME directory in every worktree.
The same redirection mechanism the superproject uses to
redirect to $MAIN_REPO/.git should be used to redirect
the sharable stuff from .git/modules/$SUBMODULE_NAME to
$MAIN_REPO/.git/modules/$SUBMODULE_NAME/.

I believe this should be the default. Optionally we might
want to enable the user to put $MAIN_REPO/.git/modules
someplace else (outside the superprojects $MAIN_REPO) to
be able to reuse the object store of submodules that are
shared between different superprojects.

Does that make sense?

On Mon, Oct 20, 2014 at 11:11 AM, Max Kirillov <max@xxxxxxxxxx> wrote:
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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]