All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Nguyễn Thái Ngọc Duy" <pclouds@gmail.com>
To: git@vger.kernel.org
Cc: "Stefan Beller" <sbeller@google.com>,
	tsniatowski@vewd.com, "Jonathan Nieder" <jrnieder@gmail.com>,
	marcnarc@xiplink.com, "Junio C Hamano" <gitster@pobox.com>,
	"Nguyễn Thái Ngọc Duy" <pclouds@gmail.com>
Subject: [PATCH 01/10] doc: about submodule support with multiple worktrees
Date: Wed, 16 Jan 2019 17:31:50 +0700	[thread overview]
Message-ID: <20190116103159.9305-2-pclouds@gmail.com> (raw)
In-Reply-To: <20190116103159.9305-1-pclouds@gmail.com>

This lays out the very first step of making multiple worktrees and
submodules work together.

The first problem is git-submodule keeps per-worktree config in
$GIT_DIR/config, which is shared for all worktrees. This series makes
git-submodule use extensions.worktreeConfig and write submodule.* to
config.worktree instead.

The rest goes on and on about the remaining problems. But let's talk a
bit more about solving the first problem. Since it relies on the
experimental extensions.worktreeConfig, this support is of course also
experimental. On the other hand, submodules have never really worked
with multi worktrees before, this change can't bite anybody.

Second problem. That is about multiple worktrees at superproject
level. At submodule level, we still can't have multiple worktrees
because git-submodule writes to submodule's "config" file
(again). Fixing this is not particularly hard. Absorbing submodule's
git dir takes some work but is feasible. This could be addressed soon
in the future.

The third problem is a big and complicaed one. Submodule clones
(inside the superproject) are per-worktree. So if you have two
worktrees, and these have one submodule, you need space for _two_
clones. This is definitely not elegant. The tenative plan is to move
clones from $GIT_COMMON_DIR/worktrees/X/modules to
$GIT_COMMON_DIR/common/modules.

The latter directory is shared across all worktrees. Once we keep the
clone in a common place, the submodule's worktree can be created and
managed with git-worktree[1].

Another good point about this approach is we could finally safely
allow "git worktree remove" to work with submodules. With current
solution, removing $GIT_COMMON_DIR/worktrees/X directory means also
removing potentially precious clones inside the "modules" subdir.

But whether we can do this depends on:

- if we need separate ref namespace for submodule on each worktree

- how does submodule's worktrees (remember the second problem)
  interact these worktrees

Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
---
 Documentation/git-worktree.txt  |  8 ++++++++
 Documentation/gitsubmodules.txt | 17 +++++++++++++++++
 2 files changed, 25 insertions(+)

diff --git a/Documentation/git-worktree.txt b/Documentation/git-worktree.txt
index aae8e1d8b2..3510fd5331 100644
--- a/Documentation/git-worktree.txt
+++ b/Documentation/git-worktree.txt
@@ -267,6 +267,14 @@ configuration that you do not want to share to all working trees:
  - `core.sparseCheckout` is recommended per working tree, unless you
    are sure you always use sparse checkout for all working trees.
 
+ - Most configuration variables under `submodule` group in superproject
+   should not be shared.
++
+------------
+$ git config --local --move-to --worktree submodule.active
+$ git config --local --move-to-regexp --worktree 'submodule\..*\..*'
+------------
+
 DETAILS
 -------
 Each linked working tree has a private sub-directory in the repository's
diff --git a/Documentation/gitsubmodules.txt b/Documentation/gitsubmodules.txt
index 57999e9f36..d91817b45d 100644
--- a/Documentation/gitsubmodules.txt
+++ b/Documentation/gitsubmodules.txt
@@ -222,6 +222,23 @@ submodule active pathspec, which specifies that any submodule
 starting with 'b' except 'baz' are also active, regardless of the
 presence of the .url field.
 
+MULTIPLE WORKING TREE SUPPORT
+-----------------------------
+When you have more than one working tree, created by
+linkgit:git-worktree[1], submodules will not work on any working tree
+until `extensions.worktreeConfig` is enabled. Since this config
+affects more than just submodules, please see "CONFIGURATION FILE"
+section for more information before turning it on.
+
+Once on, submodules can be added in any working tree. The submodule
+itself though cannot have more than one working tree.
+
+When submodules are created in a working tree, their git directory is
+also per-worktree, e.g. inside
+'$GIT_COMMON_DIR/worktrees/<worktree>/modules' and not shared with
+other working trees. This means if you have the same submodule on
+different working trees, you need disk space for multiple clones.
+
 Workflow for a third party library
 ----------------------------------
 
-- 
2.20.0.482.g66447595a7


  reply	other threads:[~2019-01-16 10:32 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-01-16 10:31 [RFC/PATCH 00/10] Support using submodules with worktrees Nguyễn Thái Ngọc Duy
2019-01-16 10:31 ` Nguyễn Thái Ngọc Duy [this message]
2019-01-16 22:06   ` [PATCH 01/10] doc: about submodule support with multiple worktrees Stefan Beller
2019-01-17 10:22     ` Duy Nguyen
2019-01-16 10:31 ` [PATCH 02/10] submodule--helper: add missing \n Nguyễn Thái Ngọc Duy
2019-01-16 10:31 ` [PATCH 03/10] submodule add: support multiple worktrees Nguyễn Thái Ngọc Duy
2019-01-16 22:27   ` Stefan Beller
2019-01-16 10:31 ` [PATCH 04/10] submodule init: " Nguyễn Thái Ngọc Duy
2019-01-16 10:31 ` [PATCH 05/10] submodule update: add tests for " Nguyễn Thái Ngọc Duy
2019-01-16 10:31 ` [PATCH 06/10] submodule sync: support " Nguyễn Thái Ngọc Duy
2019-01-16 10:31 ` [PATCH 07/10] submodule deinit: " Nguyễn Thái Ngọc Duy
2019-01-16 10:31 ` [PATCH 08/10] submodule clone: use repo_config_set() Nguyễn Thái Ngọc Duy
2019-01-16 10:31 ` [PATCH 09/10] submodule clone: propagate extensions.worktreeConfig Nguyễn Thái Ngọc Duy
2019-01-16 10:31 ` [PATCH 10/10] submodule ensure-core-worktree: write to config.worktree Nguyễn Thái Ngọc Duy

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=20190116103159.9305-2-pclouds@gmail.com \
    --to=pclouds@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=jrnieder@gmail.com \
    --cc=marcnarc@xiplink.com \
    --cc=sbeller@google.com \
    --cc=tsniatowski@vewd.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.