为什么我的提交越多，Git 子树推送的时间就越长？

Question

我一直在使用 git 子树扩展 (https://github.com/apenwarr/git-subtree) 。 我使用“--squash”来清理主项目的日志，我的步骤是这样的：

1. 将 lib 添加到主项目中

   git subtree add -P sub/libdir --squash lib_remote master

2. 从库中获取更新

   git subtree pull -P sub/libdir --squash lib_remote master

3. 将更改推送到 lib_remote

   git subtree push -P sub/libdir --squash lib_remote master

它对我来说效果很好（主项目和库，有一个很有意义的历史）。问题是git subtree push的时间，越来越长。

我使用 git-subtree 的目的和 Screndib 差不多，谁问 git-subtree is not retaining history so I cannot push subtree changes, how can I fix this/avoid this issue in the future?

我猜，在使用 --squash 时，每次处理 push 时，git subtree 都需要搜索“subtree add”以来的整个历史记录。

如何减少子树推送的时间？或者让它更有效地工作，而不是整个历史，只处理自上次 git subtree push（或 pull）以来的变化？

Answer 1

我假设你的代码中的“lib_remote”是远程库 repo 的 url，而不是你当前 repo 中的一个分支？当前仓库中的远程仓库 url 和分支都在工作。

我看到您使用git subtree add 将远程库添加为子树，然后您只使用git subtree push 推送更改。

最好在推送操作之前执行git subtree split 操作将子树更改拆分到当前仓库中的单独分支，然后将拆分的分支推送到远程仓库并保持此拆分分支存在，每次之前推送，再次执行git subtree split 操作，这将从您上次拆分的点构建子树的历史记录，它会快得多。否则，如果没有像你做的这种拆分，git subtreee 必须从你添加的点开始构建子树的历史，只要子树提交增长，构建的时间就会越来越长。

如果你在添加时不使用--squash，可以考虑在拆分时使用--rejoin，这样会快很多。

所以，步骤应该如下。

1. 将库添加到主项目中

   git subtree add -P sub/libdir --squash lib_remote_url master

2. 从库中获取更新

   git subtree pull -P sub/libdir --squash lib_remote_url master

3. 将子树更改拆分为单独的分支

   git subtree split -P sub/libdir -b lib_remote_branch

4. 将更改推送到 lib_remote

   git push lib_remote_url lib_remote_branch:master

保持 lib_remote_branch 存在，下次推送时重做第 3 步和第 4 步。

Answer 2

主要问题是自从您第一次添加以来，不同前缀上的新提交。我对这个问题的解决方案是执行“清理”操作，过滤所有不在其他存储库中的更改，然后在这个新分支上执行 git subtree add。

这是一种相当暴力的方法，但它基本上与在主存储库的新副本上执行“git subtree add”相同。这是唯一对我有用的东西......