git - 为什么 git stash -p 需要很长时间才能启动?

标签 git git-stash

在我的存储库中,git diffgit stash 都运行得很快,不到一秒。然而 git stash -p 花了整整 20 秒才显示第一个 block 。为什么会这样?

最佳答案

Git 2.25.2(2020 年 3 月)应该会改进这一点,它会简化代码。
请参阅discussion .

参见commit 26f924d (2020 年 1 月 7 日)作者:Elijah Newren (newren) .
(由 Junio C Hamano -- gitster --commit a3648c0 merge ,2020 年 1 月 22 日)

unpack-trees: exit check_updates() early if updates are not wanted

Signed-off-by: Elijah Newren

check_updates() has a lot of code that repeatedly checks whether o->update or o->dry_run are set.

(Note that o->dry_run is a near-synonym for !o->update, but not quite as per commit 2c9078d05bf2 ("unpack-trees: add the dry_run flag to unpack_trees_options", 2011-05-25, Git v1.7.6-rc0).)
In fact, this function almost turns into a no-op whenever the condition

!o->update || o->dry_run

is met.

Simplify the code by checking this condition at the beginning of the function, and when it is true, do the few things that are relevant and return early.

There are a few things that make the conversion not quite obvious:

  • The fact that check_updates() does not actually turn into a no-op when updates are not wanted may be slightly surprising.
    However, commit 33ecf7eb61 (Discard "deleted" cache entries after using them to update the working tree, 2008-02-07, Git v1.5.5-rc0) put the discarding of unused cache entries in check_updates() so we still need to keep the call to remove_marked_cache_entries().
    It's possible this call belongs in another function, but it is certainly needed as tests will fail if it is removed.
  • The original called remove_scheduled_dirs() unconditionally.
    Technically, commit 7847892716 (unlink_entry(): introduce schedule_dir_for_removal(), 2009-02-09, Git v1.6.3-rc0) should have made that call conditional, but it didn't matter in practice because remove_scheduled_dirs() becomes a no-op when all the calls to unlink_entry() are skipped.
    As such, we do not need to call it.
  • When (o->dry_run && o->update), the original would have two calls to git_attr_set_direction() surrounding a bunch of skipped updates.
    These two calls to git_attr_set_direction() cancel each other out and thus can be omitted when o->dry_run is true just as they already are when !o->update.
  • The code would previously call setup_collided_checkout_detection() and report_collided_checkout() even when o->dry_run.
    However, this was just an expensive no-op because setup_collided_checkout_detection() merely cleared the CE_MATCHED flag for each cache entry, and report_collided_checkout() reported which ones had it set.
    Since a dry-run would skip all the checkout_entry() calls, CE_MATCHED would never get set and thus no collisions would be reported.
    Since we can't detect the collisions anyway without doing updates, skipping the collisions detection setup and reporting is an optimization.
  • The code previously would call get_progress() and display_progress() even when (!o->update || o->dry_run).
    This served to show how long it took to skip all the updates, which is somewhat useless.
    Since we are skipping the updates, we can skip showing how long it takes to skip them.

关于git - 为什么 git stash -p 需要很长时间才能启动?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/49149297/

相关文章:

git - 从当前分支开始一个新的 git repo

git - TFS GIT - 如何仅提交某些文件?

python - 如何使用 docker 从代理后面运行 pip3+git?

git 找到缺失的代码吗?

node.js - openshift nodeJS 应用程序 - git 最新/服务器运行没有错误,但我仍然看到欢迎页面

git 状态 : what is UU and why should add/rm fix it?

git - 如何存储当前更改并将其应用到新分支

git - 中止 rebase 后如何应用自动存储?

git stash drop : How can I delete older stashed states without dropping the latest X?

git - 我可以从远程存储库中获取存储到本地分支吗?