5

最近我一直在使用 git stash 很多次，我一直在想它真的很慢，即使是在一个只有一个文件的新存储库上也是如此。我已经阅读了这个关于 git stash slowness 的问题和另一个问题，并尝试了这些问题的所有答案，但实际上没有任何效果。

例如，我已经完成了以下步骤来重现它：

  1. git init
  2. touch file.txt
  3. vim file.txt（编辑文件添加 2 行）
  4. git add .
  5. git commit -m "Initial commit"
  6. vim file.txt（再次编辑添加1行）
  7. time git stash

输出：

$ time git stash
Saved working directory and index state WIP on master: b9454ed Initial commit
HEAD is now at b9454ed Initial commit    
real    0m8.042s
user    0m0.000s
sys     0m0.046s

8 秒存储单行是这么多的时间。现在使用 libgit2sharp 进行测试：

static void Main(string[] args)
{
    Repository repo=new Repository(@"C:\Users\UserTest\TestGitRepo");

    repo.Stashes.Add(new Signature("test", "test@test.com", new DateTimeOffset(DateTime.Now)), "Stash on master");
}

此代码需要 74 毫秒来存储相同的更改。如果 Libgit2 这么快，那么应该可以加快git stash命令速度。我怎样才能做到这一点？

实际上使用的是 windows 10 64bit 和 git 2.11 64bits。其他 git 命令（如状态、添加、提交等）工作正常。

更新：我已经更新到 git 2.13，现在是 14,53s git stash......

更新 2：我已经更新到 git 2.15 并尝试相同的测试time git stash返回real 0m6,553s。还是很慢。。。

4

3 回答 3

3

从 Git 2.22 开始

从 Git 2.22 开始，以前的实验性功能现在是稳定的并且是默认选项。

低于 Git 2.22

一年后，安装 Git 2.19 我在 git 安装期间看到了一个复选框，用于启用新的实验性内置存储。

实验性内置 git stash

就我而言，它运行良好，并且我注意到与旧实现（使用脚本）相比，性能有了巨大的提升，而且它实际上与在 linux 中使用相同的命令一样快。

这里的结果遵循完全相同的步骤：

$ time git stash
Saved working directory and index state WIP on master: 7a29b92 Initial commit

real    0m0,120s
user    0m0,000s
sys     0m0,015s
于 2018-10-06T12:36:48.460 回答
1

要添加到现有答案，如果您已经安装了 2.19 或更高版本，则可以启用新功能：

git config --global stash.usebuiltin true

这也适用于便携版。

请注意，此功能似乎还不适用于子模块。 https://github.com/git-for-windows/git/issues/1820

于 2018-10-10T18:28:20.697 回答
0

git stash使用 Git 2.25（2020 年第一季度）会更快，其中oneway_merge()（如“reset --hard”）的用户学会了利用fsmonitor以避免不必要的lstat(2)调用。

（自 Git 2.22，Q2 2019 以来，git stash完全用 C 重写，并且是默认值）

请参阅Utsav Shah ( ) 的提交 679f2f9（2019 年 11 月 20 日）。（由Junio C Hamano 合并 -- --在提交 473b431中，2019 年 12 月 5 日）Utsav2
gitster

unpack-trees: 跳过 fsmonitor 有效文件的统计信息

帮助者：Junio C
Hamano 帮助者：Kevin Willford
签字者：Utsav Shah

索引可能知道文件没有修改 via fsmonitor，但 unpack-trees 没有注意它并检查 viaie_match_stat在某些文件系统上可能效率低下。
这会显着减慢运行的命令oneway_merge，例如checkout和git reset --hard。

此补丁oneway_merge检查文件是否被视为未更改fsmonitor并跳过ie_match_stat它。
unpack-trees 现在也可以正确地fsmonitor从源索引中复制有效性状态。最后，为了正确起见，
我们强制刷新fsmonitor.tweak_fsmonitor

在此更改之后，stash（git reset --hard内部使用）之类的命令在 mac 上的 250k 文件存储库上从 8s 或更多变为 ~2s。

于 2019-12-15T18:57:17.403 回答