将由git管理的子目录切换到子模块 [英] switching a subdirectory managed by git to a submodule

问题描述

我们曾经在Rails应用程序中使用vendor / plugins / delayed_job进行了一次delayed_job的本地攻击。它是作为一次性事件安装的，并在主应用程序仓库中检入到git中。

现在我们决定在github上fork delayed_job，并用git子模块替换子目录如所描述的那样这里：

http ：//doblock.com/articles/using-git-submodules-to-manage-plugins-in-rails

在这之前，我只是删除vendor / plugins / delayed_job，现在，尽管添加了子模块，主repo中的git status仍显示vendor / plugins / delayed_job中的新文件。

我们应该如何处理这样一种情况，即删除了属于回购协议一部分的子目录，并使其保留git子模块？我们应该先使用git rm删除它，或者更彻底地删除它，然后再将子模块克隆到它的位置？

您不关心工作树中 vendor / plugins / delayed_job 的当前内容（即，将作为子模块检出的内容已经是适用于在工作树中的内容），将目录转换为子模块的正常过程如下所示：

  git rm -r vendor / plugins / delayed_job 
 git submodule add github.com:account/delayed_job.git vendor / plugins / delayed_job 
  

当然，GitHub仓库URL可能会有所不同;例如，您可能想要使用HTTP URL而不是上述SSH URL。

但是，您似乎做了一些与众不同的事情。尽我所能，你做了这样的事情：

  rm -rf vendor / plugins / delayed_job 
 git clone github.com:account/delayed_job.git vendor / plugins / delayed_job 
  

这个过程有两个缺陷：

1. 简单的 rm 会将旧文件保留在您的Git索引中。


2. 直接克隆为您提供了subrepository，但不是官方子模块。
   

假设您在 vendor / plugins / delayed_job 中没有任何有意的阶段性变化（你可能不需要，因为你用一个子模块替换它），你可以用这些命令：

  git rm --cached -r vendor / plugins / delayed_job 
 git submodule add github.com:account /delayed_job.git vendor / plugins / delayed_job 
  

清除所有供应商/插件/ delayed_job 来自索引的条目应该修复你的仍然显示新文件的问题。使用 git submodule add 将创建 .gitmodules 文件，该文件将subrepository转换为真正的子模块。

We used to have a local hack of delayed_job in a Rails app, in vendor/plugins/delayed_job. It was installed as a one-time event and checked into git in the main app repo.

Now we decided to fork delayed_job on github and replace the subdirectory by a git submodule, as described e.g. here:

http://doblock.com/articles/using-git-submodules-to-manage-plugins-in-rails

Before doing that, I simply removed vendor/plugins/delayed_job, without checking it in. Now, despite adding the submodule, git status in the main repo still shows new files in vendor/plugins/delayed_job.

How should we handle the situation where a subdirectory which was a part of the repo is deleted and made to hold a git submodule? Should we first delete it with git rm, or obliterate it even more thoroughly, before cloning a submodule into its place?

解决方案

Assuming that you do not care about the current contents of vendor/plugins/delayed_job in your working tree (i.e. the content that will be checked out as a submodule is already a suitable replacement for the content in your working tree), the normal procedure for converting a directory into a submodule looks like this:

git rm -r vendor/plugins/delayed_job
git submodule add github.com:account/delayed_job.git vendor/plugins/delayed_job

Of course, the GitHub repository URL may vary; for example, you may want to use an HTTP URL instead of the above SSH URL.

But, it seems like you did something a bit different. As best I can tell, you did something like this:

rm -rf vendor/plugins/delayed_job
git clone github.com:account/delayed_job.git vendor/plugins/delayed_job

There are two flaws with this procedure:

1. The plain rm leaves the old files in your Git index.
2. Directly cloning gives you a "subrepository", but not an official submodule.

Assuming that you do not have any intentionally staged changes in vendor/plugins/delayed_job (you probably do not, since you are replacing it with a submodule), you can clean up the situation with these commands:

git rm --cached -r vendor/plugins/delayed_job
git submodule add github.com:account/delayed_job.git vendor/plugins/delayed_job

Cleaning out all the vendor/plugins/delayed_job entries from the index should fix your "still shows new files" problem. Using git submodule add will create the .gitmodules file which turns the "subrepository" into a true submodule.

这篇关于将由git管理的子目录切换到子模块的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！