合并回从'git filter-repo'创建的子目录

如何解决合并回从'git filter-repo'创建的子目录

假设我的存储库具有这样的文件夹结构：

const goalValue = 3;
const data = [{ name: 'A',minimum: 1},{ name: 'A',minimum: 2},minimum: 5} ];

let minDifference = Number.MAX_SAFE_INTEGER;
let elIndex;

data.forEach((el,index) => {
  let diff = Math.abs(el.minimum - goalValue);
  if(diff < minDifference){
    minDifference = diff;
    elIndex = index;
  }
})

console.log(data[elIndex]);

我在“ dir-2”目录上执行“ git filter-repo”。现在我的文件夹结构是：

Base
|-dir1
|-dir2
| |-subdir1
| |-subdir2
| |-subdir3
|-dir3

对'dir2'中存在的文件进行了一些更改之后，我想将其合并回原来的仓库，并从该仓库中过滤掉它，并再次像下面这样恢复结构：

Base
|-dir2
| |-subdir1
| |-subdir2
| |-subdir3

如何保存历史记录？

解决方法

如何保存历史记录？

在Git中，对于这个问题有一个普遍的答案-即我如何在保留历史的同时_____？-对于任何可以弥补这个空白的即：在Git中，历史就是提交。提交是历史。那就是所有的历史。如果您拥有所有提交，那么您将拥有所有历史记录。

因此，关于合并的特定问题的答案很简单：进行合并，并确保结果是您想要的。新提交只需将 add 添加到现有提交中即可，即只需添加更多历史记录即可。古老的历史仍然存在。

这里的微妙之处在于，您看到的历史取决于您所处的位置。如果您从合并之前的位置运行git log，那么您将看到的历史记录就是您之前看到的历史记录。但是，如果您在合并时或合并后的任意时刻运行git log，您将看到的历史记录可能会有所不同。尽管这种类比充其量是令人怀疑的，但您可以将其视为从近处观察一个装满作物的田地，然后尝试在您和装满作物的田地之间查看一个大城市的同一个田地。字段并没有改变，由于所有高大的建筑物挡住了您的视线，您现在无法看到。

在Git中查看历史记录时，如果您使用git log --follow或git diff --find-renames，则Git将尝试检测重命名的文件。也就是说，我们有两个提交，每个提交代表您（或任何人）提交提交时Git知道的所有文件的快照。我们在左侧放置一个较旧的快照 L ，在右侧放置一个较新的快照 R ，并询问Git： L和R之间发生了什么变化？

也许在 L 中有一个名为O的文件，在 R 中不再存在。但是在 R 中，有一个名为N的文件，在 L 中不存在。如果重命名检测器已打开，Git将尝试推断O和N是否表示相同文件。（这进入到metaphysics of identity中，由祖父的斧头或Ship of Theseus问题表示。）如果Git判定O和N 相同文件，Git会声称O已重命名为N，并向您显示了这两个文件内容之间的差异（如果有）。否则，Git会声称O已被删除并且N已创建。

这又是您在Git中可以获得的全部内容。重要的是要知道何时 Git将决定重命名文件，而删除一个文件后再创建另一个文件，但是认识到这些代表同一件事也很重要>。此外，您可以打开或关闭Git的重命名检测器，并且可以在一定程度上进行微调。此处围绕合并提交存在一些陷阱，目前尚无简单的解决方案。

也就是说，就保存历史而言，请记住：提交是历史。如果您拥有所有提交，那么您将拥有所有历史记录。