问题标签 [git-mv]

我已经阅读了几个关于在 git 存储库之间移动目录的主题，我决定使用的是这个，它使用git subtree.

按照步骤，一切似乎都运行良好，但问题到了最后。

我留下了一个新的存储库，我想移动的目录的所有内容都在根目录中。如果我将 agit mv内容放入我想要的子目录，当我做 a 时git log -- sub\dir\1，从那里看不到历史记录。历史仅从根可见。

我计划以这种方式移动多个目录，所以它会有点影响，因为现在我必须git log --follow在我查找历史记录的每个文件上使用。

有没有其他方法，或者我做错了什么，以便我可以将历史保存在正确的子目录下？如果有帮助，我在新仓库中想要的文件夹结构实际上与旧仓库中的文件夹结构相同（嗯，至少在git subtree命令之前）。

明确地说，这是我开始的内容：

这是我现在的位置：

这是我真正想要的：

当使用 重命名文件时git mv，提交将显示 rename from 和 rename to，并且在 pull request 中显示相同，这很好。但是当一个文件被git mv编辑然后更改时，看起来有一个阈值，当更改的行数超过它时，它将不再显示为重命名，而是显示为删除旧文件并添加新文件。所以我的问题是这个阈值是一个定义明确的数字吗？还有没有其他方法可以让它变得更好，主要是因为在 pull request diff 中，当两个文件不考虑重命名时，diff 不会并排显示，这使得审查变得困难。

关于处理重命名还有其他答案merge，但我的情况很复杂，我认为它需要一个单独的问题。

我们有一个 git 项目，最初由 20 多个存储库组成。我们使用包装脚本来处理许多标准的 git 操作。因为我们现在正在迁移到 GitHub，所以我们无法以这种方式处理项目。

因此，我们将所有存储库移动到一个存储库中，基本上使用了saintgimp中描述的方法。当然，这意味着所有文件现在都已重命名，但 SHA 在历史上是相同的。

好的，所以现在我想将 branch 合并source到 branch target，注意我确保两者在最终切换之前同步。我的第一次尝试，使用git merge <source>引起了成千上万的冲突，抱怨在一侧或另一侧更改/删除的文件等。

然后我在Advanced Merging 页面上找到了一个 gem ：

如果你想做这样的事情，但没有让 Git 尝试合并来自另一端的更改，有一个更严格的选项，即“我们的”合并策略。这与“我们的”递归合并选项不同。

啊，这听起来像我需要的。好的，我执行了以下操作：

SHA统一的最后一次提交在哪里。换句话说，我希望所有历史，包括SHA，都被认为已经合并到target. 我希望这将是一次合并，并会修复所有未来的合并。

现在，当我尝试从 合并第一个新提交时source，效果是正确的，但我继续收到以下警告：

而且，事实上，如果我设置renamelimit为 10000，下一次合并（调用它B）会在没有警告的情况下执行，但代价是性能要慢得多。再一次，一次性成本是可以接受的，如果我的后续合并再次正常，我将支付该成本。

下一次合并，C我使用默认值的地方renamelimit，再次给出警告。

所以，最后，我的问题是：我怎样才能让 git 相信target分支是同步的，source这样它就不会在统一之前停止尝试回到历史？renamelimit由于性能下降，我希望能够在不增加的情况下合并。

以一个项目为例，主存储库 M 中的可执行源和几个子模块 S1、S2 等中的依赖库。决定将可执行文件中的一些代码迁移到子模块 S1 中的库中其他项目通常可以访问。我们将主存储库和子模块都分支，迁移过程的第 1 步是简单地将 N 个文件从 M 中的目录移动到 S1 中的特定目录（具有不同的路径）。天真的方法是简单地从 M 中 git rm 文件，将它们移动到 S1 中的新目录，cd 到子模块，然后 git add 它们。问题当然是这些文件的所有历史记录都丢失了。这不是一个大问题，因为我认为例如 pull-merge 不会跟踪从 M 中的文件到 S1 中的新家的更改，

所以这就是我的问题：有没有比简单的 rm-and-add 更好的方法来完成从 M 到 S1 的文件迁移，这样至少可以保留文件的历史记录。如果它在 M 之内，当然可以简单地使用 git-mv。我已经看到了一些在任意存储库之间移动文件的公式，但是 A，我发现它们几乎不可能遵循，而 B，我希望主模块和子模块之间的托管关系可能会使它更容易或更优雅地完成。如果答案是出于这些目的，M 和 S1 只是两个任意不同的存储库，那么这里的某个人可能会以比我在其他地方看到的更好的方式列出这些步骤并进行解释。这实际上是我现在正在研究的一项任务，因此我们将不胜感激任何相关的反馈。

编辑：合理地建议这是Git: Moving files into an existing submodule 的副本。这似乎是真的，这并不让我感到惊讶，这已经被提出了，但对于一个对 git 有相当基本了解的读者来说，答案是相当简洁的。我希望通过对所涉及命令的更完整描述来分解这些步骤。

Edit2：在我看来，所谓的 dup（以及其他类似问题和答案）的答案对我不起作用的原因有两个。一方面，为了了解正在做的事情，我需要阅读所有这些内容，只是因为我需要加深我对 git 正在发生的事情的模型。那在我身上。但是在完成了这些之后，现在了解了这些拆分和合并方法正在发生的事情，我意识到我试图解决的问题更深入——事实上，如此之深，以至于我开始意识到它可能git 无法交付的独角兽。

当你有一个单一的存储库 - 没有子模块时，你可以移动一个文件git mv，并且它为系统提供了更多信息，而不是简单地从一个位置删除并添加到另一个位置。它保留了历史，但我相信它还允许 git 跟踪在移动文件中所做的更改，无论它们在其他本地存储库中的什么位置。因此，如果我将我的文件移动到一个分支中，而其他人在他们自己的文件视图中修改文件并提交并推送这些更改并将它们合并到主分支，那么我相信 git 有足够的会计信息，当我提取这些更改时，它们在我的存储库视图中被合并到新位置的文件中。这是一个比仅仅保存历史更大的附加值（在我看来）。如果我从主存储库中删除文件并将它们添加到子模块中，它们在新位置将没有历史记录，但是他们在旧位置的生活历史仍然可以通过已删除文件的“幽灵”来检索。不方便，但不是灾难性的。但是，如果有一种方法可以管理来自其他开发人员视图的更改并将它们定向到存在于子模块中的文件，那将是惊人的。太神奇了，这似乎超出了 git 的能力范围。总而言之，我想我正在寻找一个可以跨存储库工作的神奇“git mv”，现在我想起来，我怀疑这样的事情是否存在。太神奇了，这似乎超出了 git 的能力范围。总而言之，我想我正在寻找一个可以跨存储库工作的神奇“git mv”，现在我想起来，我怀疑这样的事情是否存在。太神奇了，这似乎超出了 git 的能力范围。总而言之，我想我正在寻找一个可以跨存储库工作的神奇“git mv”，现在我想起来，我怀疑这样的事情是否存在。

在 git repo 中，我不小心将文件 , 移动A到B，而不是删除A并创建一个全新的B.

如何在变基期间删除A并创建新的？B

我有一些csv我定期修改的文件，它们实际上并不包含任何敏感信息，它们只是用作程序的导入，我会根据要求对其进行修改。

最近我发现了处理更改的更有效方法，但我在项目外部的临时 git 存储库上对其进行了测试。

由于这很成功，我现在想要对其进行更改git cherry-pick的范围，所以首先我将临时 git repo 作为远程添加到我的项目中。

（事后看来，我认为这是一个错误，我应该在现有项目中削减另一个分支，但我离题了）

临时存储库只有一个主分支，并且所有内容都在项目的根目录中完成了一系列提交。

当我cherry-pick对我的项目和本地分支进行更改时，这些csv文件最终都在我的项目的根目录中，但它们属于src/csv我的项目的文件，所以我决定rebase从一开始就进行交互提交的范围（减去 1 次提交）并编辑每个，以便更改显示在我的项目存储库中的src/csv目录而不是根目录中。

但是我的问题是，如果我想这样做，我应该使用git mv移动文件还是仅使用标准 bashmv命令，然后使用 rebase 重新应用每个更改，并将相应的提交消息添加到临时项目中。

到目前为止，我已经尝试git mv -f在第一次提交时移动文件，并且在运行之前提交它们时甚至没有提到更改git rebase --continue。

我还应该做些什么来使这个过程更顺利，我假设我应该使用mv而不是git mv -f因为在提交之前更改似乎以这种方式显示。

我还想保留提交消息，而不必从旧仓库的日志中复制它们。

我有一个文件：

a.cs

我将其重命名为：

b.cs

并在 b.cs 中进行了一些逻辑更改

现在我意识到我需要重新添加 a.cs 但保留 b.cs。

我添加了 a.cs 但在工作目录中看不到它，因此无法将其添加到暂存区域并提交。

在遥控器中，我看到 b.cs 已重命名。

我认为这是因为我重命名了原始文件而不是删除它。

我知道 mv 命令，但我不知道如何在这种特定情况下使用它

所以我现在需要的是，如果可能的话，加回 a.cs 并仍然保留 b.cs？

更新 好的 - 所以这是错误的。该文件被添加回来。对困惑感到抱歉。

git rev-list输出文件路径的所有版本（在重命名处停止），git --follow --pretty=%h输出跨移动/重命名的所有版本，但是我如何（非手动）找到修改文件内容的最新提交（最好chmod也排除 's ）？

就我而言，我有一个文件被多次重命名，但我想在更改它的最新提交之前重新设置基准。

我已经将一堆文件移动到一个单独的分支，以避免混合不同的历史。然后我将新分支上的文件移动到/（以便它们可以在根植于它们最初所在位置的工作树中签出）：

现在，当然，虽然两个分支上的新历史看起来都很干净，但我在查看过去的历史时遇到了麻烦。git log --follow需要一个文件名。

在主分支上，我可以

• xargs -0 -a <(git ls-files -z) git log --（获取现有文件的日志）

在脚本branch上，它不是那么简单；我想我需要

• 找到现有文件的所有以前的名称，然后是git log当前 + 旧名称（尽管这可能是很多参数）。如何？
• git log忽略引用已删除（但未重命名）文件的提交（这似乎不可行）

想法？

我有一个目录 'Checkout' 需要移动到目录 'screens'。我不想覆盖屏幕文件夹，我只想将 Checkout 添加到它。这一切都在本地机器上。

到目前为止，我已经创建并导航到了一个新分支。这个想法是移动这个分支中的整个目录，添加/提交更改，然后将这个分支与更改的目录位置推送到远程。

我试过这个命令...

git mv app/Checkout ... app/screens

但我明白了

fatal: bad source, source=..., destination=app/screens/...

我错过了什么？