From: Jens Lehmann <Jens.Lehmann@web.de>
To: Duy Nguyen <pclouds@gmail.com>, Max Kirillov <max@max630.net>
Cc: Junio C Hamano <gitster@pobox.com>,
Heiko Voigt <hvoigt@hvoigt.net>,
Johannes Schindelin <johannes.schindelin@gmx.de>,
Git Mailing List <git@vger.kernel.org>
Subject: Re: [PATCH 0/4] Multiple worktrees vs. submodules fixes
Date: Mon, 03 Nov 2014 21:57:13 +0100 [thread overview]
Message-ID: <5457EC29.8040005@web.de> (raw)
In-Reply-To: <CACsJy8C34PyK4rPQC_wFgms=gVCs2FN_5aUSMfzJawErZHHwFg@mail.gmail.com>
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@max630.net> 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
>
>
>
next prev parent reply other threads:[~2014-11-03 20:57 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-10-12 5:13 [PATCH 0/4] Multiple worktrees vs. submodules fixes Max Kirillov
2014-10-12 5:13 ` [PATCH 1/4] checkout: do not fail if target is an empty directory Max Kirillov
2014-10-12 5:13 ` [PATCH 2/4] submodule refactor: use git_path_submodule() in add_submodule_odb() Max Kirillov
2014-10-12 5:13 ` [PATCH 3/4] git-common-dir: make "modules/" per-working-directory directory Max Kirillov
2014-10-12 5:13 ` [PATCH 4/4] path: implement common_dir handling in git_path_submodule() Max Kirillov
2014-10-14 12:17 ` [PATCH 0/4] Multiple worktrees vs. submodules fixes Duy Nguyen
2014-10-14 17:09 ` Jens Lehmann
2014-10-14 17:26 ` Junio C Hamano
2014-10-14 18:34 ` Max Kirillov
2014-10-14 19:51 ` Jens Lehmann
2014-10-14 22:15 ` Max Kirillov
2014-10-15 14:14 ` Duy Nguyen
2014-10-15 18:57 ` Jens Lehmann
2014-10-16 20:54 ` Max Kirillov
2014-10-19 19:30 ` Jens Lehmann
2014-10-20 4:11 ` Max Kirillov
2014-11-03 12:54 ` Duy Nguyen
2014-11-03 20:57 ` Jens Lehmann [this message]
2014-11-03 22:07 ` Max Kirillov
2014-10-14 20:31 ` Max Kirillov
2014-10-15 13:08 ` Duy Nguyen
2014-10-15 17:09 ` Junio C Hamano
2014-10-17 9:14 ` Duy Nguyen
2014-10-19 19:34 ` Jens Lehmann
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5457EC29.8040005@web.de \
--to=jens.lehmann@web.de \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=hvoigt@hvoigt.net \
--cc=johannes.schindelin@gmx.de \
--cc=max@max630.net \
--cc=pclouds@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).