减少增加推送子树的时间

fer*_*ith 16 git github git-subtree

我在我的项目中使用,它包含几个子项目.每个子项目使用命令在主项目中"链接" .这是我在实现"svn externals"的方式.我几周以来一直在使用它,但是在每次提交期间,将我的更改从子树推送到远程位置的时间都会增加.当我使用命令推送更改时,它看起来像这样

git subtree push -P platform/rtos rtos master

git push using:  rtos master

1/    215 (0)2/    215 (1)3/    215 (2)4/    215 (3)5/    215 (4)6/    215 (5)7/    215 (6)8/    215 (7)9/    215 (8)10/    215 (9)11/    215 (9)12/    215 (10)13/    215 (11)14/    
....

20 more lines

....

(204)209/    215 (205)210/    215 (206)211/    215 (207)212/    215 (208)213/    215 (209)214/    215 (210)215/    215 (211)To https://github.com/rtos/rtos.git
   64546f..9454ce  9a9d34c5656655656565676768887899898767667348590 -> master
Run Code Online (Sandbox Code Playgroud)

有没有办法"清理"子树,从而减少推动更改的时间?

Lop*_*Sae 13

尝试使用该--rejoin标志,以便在拆分后将子树正确合并回主存储库.这样每次拆分都不需要经历所有历史记录.

git subtree split --rejoin --prefix=<prefix> <commit...>
Run Code Online (Sandbox Code Playgroud)

原始子树文档:

拆分后,将新创建的合成历史记录合并回主项目.这样,未来的拆分只能搜索自最近的--rejoin以来添加的历史部分.

  • 并使用哪个<commit ...>?我尝试了那个子树的提示,虽然它做了拆分/重新连接(甚至不确定这意味着什么),我的下一个子树推送同样冗长:( (3认同)
  • 为什么会这样(你能解释一下当你使用 split/rejoin 时会发生什么吗)?我需要多久运行一次(一次?每个未指定事件一次?每次推送之前?) (2认同)

Chr*_*ial 6

不,不幸的是没有。运行时git subtree push,它将重新创建此子树的所有提交。它必须这样做,因为它们的 SHA 取决于先前的提交,并且需要这些 SHA 能够将新提交链接到旧提交。它可以缓存它,但它没有。

我想这是您使用子树与子模块所付出的代价。子树在您的存储库中是非常无状态的,这在一方面很好,但另一方面会导致计算时间过长。子模块存储它们的所有信息,这需要您对其进行管理,但也使这样的事情变得更快。

  • 令人惊讶的是 `git subtree` 不能(不是吗?)只是缓存这些信息,所以在第一个 `git subtree push` 之后,一切都变得相对活泼。 (7认同)
  • 尤其是在 Windows 上,这非常慢。在我的情况下,当您达到 600 断言计数时,每次推送需要超过一分钟的时间,使 git 在那时变得无用。 (2认同)

Von*_*onC -6

请注意,如果您决定切换到git submodule,您现在可以,因为 git1.8.2 (2013-03-08)跟踪子模块 repo 的最新提交

请参阅git 外部

“git submodule”开始学习一种新模式来与远程分支的尖端集成(而不是与超级项目的 gitlink 中记录的提交集成)。

这可以实现更快的推送,同时受益于子模块在子树上拥有的附加信息(即子模块的特定提交的轻量级记录)

您可以使用以下命令将该子模块更新为给定分支的最新版本:

git submodule update --remote
Run Code Online (Sandbox Code Playgroud)

该选项仅对命令有效update
不要使用超级项目记录的 SHA-1 来更新子模块,而是使用子模块的远程跟踪分支的状态。

  • 不错的选择,但这个问题是关于子树的。能找到答案就太好了。 (8认同)