使用git子模块使用git worktree会出什么问题 [英] What goes wrong when using git worktree with git submodules

问题描述

我最近发现了 git worktree 命令：

新的工作目录链接到当前的存储库，共享除HEAD，索引等工作目录特定文件以外的所有内容。

但文件也显示

...对子模块的支持不完整。不建议多次签出一个超级项目。

没有关于错误发生的进一步解释。

有人能够指导我预期的问题吗？例如，如果我使用这种方式生成的单独的工作树仅适用于不影响子模块的更改，我会没事吗？ 解决方案

提交a83a66a 相当明确：

git-submodule.sh 期望 $ GIT_DIR / config 至至少对于子模块*部分。

这里我认为我们有两个选择：

• 或者更新 config.c 来读取
  $ GIT_DIR / config。除了
$ GIT_DIR / config （共享）之外，还有worktree （这是每个工作树），并将工作特定的变量存储在新的
  地方，
  
• 或更新 git-submodule.sh 来读取/写入子模块。 直接从 $ GIT_DIR / config.submodule （每工作树）
  。

这些都需要时间来正确解决。同时，请记住
用户他们不应该在子模块上下文中使用多个工作区。

更普遍的是，其中放置这些子模块？

有几个选项：

• 您可能希望在 $ SUPER $ SUB repos其他地方（可能位于中央
  的位置） C $ C>。对于嵌套子模块
  也是如此，其中超级项目可能是另一个超级项目的子模块。


• 您可能希望保留所有 $ SUB $ SUPER / modules （或
  中的其他地方 $ SUPER ） / li>
  
• 我们甚至可以进一步推进并将所有 $ SUB 回购合并到 $ SUPER
  ，而不是单独存储它们。但至少需要启用
  ref命名空间。
  

这个提交是一个答案提交df56607 。

---

从git用户的角度来看，这意味着一个 git子模块更新--init --recursive 不完全知道 where 来检出子模块。

它们是否跨所有工作树重复使用，还是集中在某处？这还没有正式指定。

---

一年后（并且使用git 2.9）， clacke 增加在评论中

混淆已解决，但不是一个最佳方式。

子模块现在可以正常工作了，但我可以看到，但是每个工作树都有自己的子模块回购集（ motherrepo.git / worktree /< ; worktreename> / modules /< submodule> ），所以如果你有一个很大的子模块，你会遇到一些严重的磁盘使用。 blockquote>

---

处理子树中子模块的别名：

• https://gitlab.com/clacke/gists/blob/0c4a0b6e10f7fbf15127339750a6ff490d9aa3c8/.config/git/config#L11


• https://gitlab.com/clacke/gists/blob/0c4a0b6e10f7fbf15127339750a6ff490d9aa3c8/.config/git / config＃L12

别名 git wtas 预计 git wta 全局定义，或者至少对于所有涉及的回购定义。不包括保修。如果您的路径名称中包含空格，您最喜欢的宠物可能会感染痛苦。

它期望在您的回购库中有一个结构，就像非子回购所以如果你有一个裸回购，你将不得不模仿这个设置。 （不是路径） foo 的子模块进入< your-.git-directory> / modules / foo （不是 ... / foo.git ）。它不会崩溃，如果一些模块不存在于回购中，它只是跳过它。

有改进的空间。它不处理子模块内的子模块，它只向下一级。它可能只是将子模块 git wta 调用更改为 git wtas 调用，但我还没有验证。

- clacke

---

另请参阅 git worktree move （使用Git 2.17+，Q2 2018）。

I recently discovered the git worktree command:

The new working directory is linked to the current repository, sharing everything except working directory specific files such as HEAD, index, etc.

But the docs also indicate

… the support for submodules is incomplete. It is NOT recommended to make multiple checkouts of a superproject.

without further explanation as to what goes wrong.

Can someone enlighten me about the problems to expect? For example, will I be fine if I use the separate worktrees generated this way only for changes that do not affect the submodules?

解决方案

Commit a83a66a is quite clear about that:

git-submodule.sh expects $GIT_DIR/config to be per-worktree, at least for the submodule.* part.
Here I think we have two options:

• either update config.c to also read $GIT_DIR/config.worktree (which is per worktree) in addition to $GIT_DIR/config (shared) and store worktree-specific vars in the new place,
• or update git-submodule.sh to read/write submodule.* directly from $GIT_DIR/config.submodule (per worktree).

These take time to address properly. Meanwhile, make a note to the user that they should not use multiple worktrees in submodule context.

More generally, where to put those submodules?

There are a couple options:

• You may want to keep $SUB repos elsewhere (perhaps in a central place) outside $SUPER. This is also true for nested submodules where a superproject may be a submodule of another superproject.
• You may want to keep all $SUB repos in $SUPER/modules (or some other place in $SUPER)
• We could even push it further and merge all $SUB repos into $SUPER instead of storing them separately. But that would at least require ref namespace enabled.

This commit was an answer to commit df56607.

---

From a git user point of view, that means a git submodule update --init --recursive does not know exactly where to checkout the submodules.
Are they duplicated across all worktrees, or are they centralized somewhere? This isn't formally specified yet.

---

A year later (and with git 2.9), clacke adds in the comments

the confusion has been resolved, but not in an optimal manner.
Submodules work fine now as far as I can see, but each worktree has its own set of submodule repos (under motherrepo.git/worktree/<worktreename>/modules/<submodule>), so if you have a submodule that's big, you are facing some serious disk usage.

---

Git aliases to handle submodules in subtrees:

• https://gitlab.com/clacke/gists/blob/0c4a0b6e10f7fbf15127339750a6ff490d9aa3c8/.config/git/config#L11
• https://gitlab.com/clacke/gists/blob/0c4a0b6e10f7fbf15127339750a6ff490d9aa3c8/.config/git/config#L12

The alias git wtas expects that git wta is defined globally, or at least for all the repos involved. No warranty included. Your favorite pet may catch a painful infection if your path names have spaces in them.

It expects a structure in your repo like the one in a non-bare repo with submodules initiated, so if you have a bare repo, you'll have to mimic that setup. A submodule with the name (not path) foo goes in <your-.git-directory>/modules/foo (not .../foo.git). It will not crash if some module is not present in the repo, it just skips it.

There is room for improvement. It does not handle submodules within submodules, it only goes one level down. It may work to just change the submodule git wta call to a git wtas call, but I haven't verified this yet.

-- clacke

---

See also git worktree move (with Git 2.17+, Q2 2018).

这篇关于使用git子模块使用git worktree会出什么问题的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！