移动一个包含子模块的git工作副本 [英] Moving a git working copy containing submodules

问题描述

最近Git的一个变化改变了当使用子模块时处理 .git 目录的方式。
不是每个子模块都有一个 .git ，现在所有东西都在根级 .git 目录（与包含子模块的工作副本相对应的目录）。

然后，在每个子模块中创建一个文件，该文件指向<$ c的新位置$ c> .git 目录。

在我的项目，我有以下 .gitmodules 文件：

  [submoduletests / shared-tests] 
 path = tests / shared-tests 
 url = git：//github.com/roboptim/roboptim-shared-tests .git 
 [submodulecmake] 
 path = cmake 
 url = git：//github.com/jrl-umi3218/jrl-cmakemodules.git 
  

当我做 git clone --recursive 时，我得到：

  $ cat cmake / .git 
 gitdir：/home/moulard/profiles/default-x86_64-linux-ubuntu-12.04。 1 / SRC /未stable / roboptim / roboptim-core / .git / modules / cmake 
  

我目前使用Git 1.8。 1.5。

我的问题是：

1. 为什么这种行为会改变？我看不出这个新战略有什么明显的收获。


2. 那么我该如何安全地移动一份工作副本？ （如果我移动我的工作副本，则会收到一条错误消息，告诉我破坏的gitdir的路径不再是Git存储库）

<请注意，这与前面的问题不一样移动包含子模块的git存储库的父目录，因为我是确定，这不是与我的<$中存在绝对路径相关的问题c $ c $ .gitmodules file。

解决方案 .git /模块组织的日期从 git1.7.8（2011年12月2日）：

当使用<$填充新的子模块目录c $ c> git submodule init ， $ GIT_DIR 元信息目录子模块创建在超级项目的 $ GIT_DIR / modules /< name> / 目录中，并通过gitfile机制引用。

This是为了能够在没有重新克隆的情况下在树中拥有和没有子模块的超级项目中进行提交。。

但是，最近的错误修复已包含在 1.8.2.1 和 1.8.3 （2013年4月22日）：

git submodule update，recursed到子子模块，并没有统计前缀路径。

因此，升级到最新的git版本可以解决这个问题。 p>

---

在这里，一个可能的解决方案最新的git 1.8.3，2013年4月，22d）， OP Thomas Moulard 在评论：

$ git submodule deinit -f。正在工作！

然后我可以运行 git submodule init ，路径得到修复

）初始化步骤（ .git / modules ）

它不会照顾'<$ c $在 .gitmodules 文件中记录子模块的URL的步骤：c> add '步骤：您仍然需要在该文件中手动删除它。 / p>

A recent change in Git changed the way the .git directory is handled when using submodules. Instead of having one .git per submodule, everything is now in the "root level" .git directory (the one corresponding to the working copy including the submodules).

Then, in each submodule, a file is created which points to the new location of the .git directory.

In my project, I have the following .gitmodules file:

[submodule "tests/shared-tests"]
        path = tests/shared-tests
        url = git://github.com/roboptim/roboptim-shared-tests.git
[submodule "cmake"]
        path = cmake
        url = git://github.com/jrl-umi3218/jrl-cmakemodules.git

When I do git clone --recursive, I then obtain:

$ cat cmake/.git
gitdir: /home/moulard/profiles/default-x86_64-linux-ubuntu-12.04.1/src/unstable/roboptim/roboptim-core/.git/modules/cmake

I am currently using Git 1.8.1.5.

My questions are:

1. Why did this behavior change? I don't see any obvious gain to this new strategy.
2. How can I then move safely a working copy? (if I move my working copy, I get an error message telling me that the path to the broken gitdir is not a Git repository anymore)

Please note that this is not the same as the previous question Moving the parent directory of a git repository that contains submodules in the sense that I am sure this is not an issue related by the presence of an absolute path in my .gitmodules file.

解决方案

The .git/module organization dates back from git1.7.8 (December 2d, 2011):

When populating a new submodule directory with "git submodule init", the $GIT_DIR metainformation directory for submodules is created inside $GIT_DIR/modules/<name>/ directory of the superproject and referenced via the gitfile mechanism.
This is to make it possible to switch between commits in the superproject that has and does not have the submodule in the tree without re-cloning.

However, recent bug fixes have been included in 1.8.2.1 and 1.8.3 (April 22d, 2013):

"git submodule update", when recursed into sub-submodules, did not acccumulate the prefix paths.

So upgrading to the very latest git release could fix this issue.

---

Here, one possible solution (with the latest git 1.8.3, April, 22d 2013), is mentioned by the OP Thomas Moulard in the comments:

$ git submodule deinit -f . is working!
Then I can run git submodule init and the paths get fixed

This takes care if the (de)initialization steps (.git/modules)

It doesn't take care of the 'add' step which records the url of a submodule in the .gitmodules file: you still need to remove it manually within that file.

这篇关于移动一个包含子模块的git工作副本的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！