From: Jens Lehmann <Jens.Lehmann@web.de>
To: Max Kirillov <max@max630.net>
Cc: Junio C Hamano <gitster@pobox.com>,
Duy Nguyen <pclouds@gmail.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: Sun, 19 Oct 2014 21:30:15 +0200 [thread overview]
Message-ID: <54441147.5080204@web.de> (raw)
In-Reply-To: <20141016205453.GA8441@wheezy.local>
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.
> Maybe, there could be some options to tell the command which
> populates submodules (which commands that are? "submodule update"
> and other submodule subcommands? or there is something
> else?) to use the curent checkout space or the main one. But
> I would still leave it depend on what user explicitly calls
> and where the initial submodule update is executed.
Currently only "submodule update" populates submodules, but
I'm currently working hard on teaching commands like checkout
(and lots of others) to do the same. I agree that the user
should be able to choose and for our CI server I would also
like to see a solution that could share submodules across
different superprojects. So having another environment
variable to decide where to put the work tree independent
parts of the .git/modules directory might make sense here.
> 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.
next prev parent reply other threads:[~2014-10-19 19:30 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 [this message]
2014-10-20 4:11 ` Max Kirillov
2014-11-03 12:54 ` Duy Nguyen
2014-11-03 20:57 ` Jens Lehmann
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=54441147.5080204@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).