Noticed big performance issue when fetching multiple refs with depth 1 enabled

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Thank you for filling out a Git bug report!
Please answer the following questions to help us understand your issue.

What did you do before the bug happened? (Steps to reproduce your issue)
Do a git fetch --depth=1 , with no remote changes, having a lot of
remote branches makes the issue more visible
What did you expect to happen? (Expected behavior)
Shallow fetch should be faster or as fast as a full fetch
What happened instead? (Actual behavior)
Shallow fetch is about 10x slower than full fetch, consistently
What's different between what you expected and what actually happened?
I expected the shallow fetch to be faster than a normal fetch, or as
fast. Did not expect it being 10x slower.
Anything else you want to add:
Tested in a repository with ~10000 remote branches, a single Github
hosted remote.
Also tested with a local remote, and Git 2.35.1 version, with
comparable results.
Please review the rest of the bug report below.
You can delete any lines you don't wish to share.


[System Info]
git version:
git version 2.32.0 (Apple Git-132)
cpu: x86_64
no commit associated with this build
sizeof-long: 8
sizeof-size_t: 8
shell-path: /bin/sh
uname: Darwin 20.6.0 Darwin Kernel Version 20.6.0: Tue Feb 22 21:10:41
PST 2022; root:xnu-7195.141.26~1/RELEASE_X86_64 x86_64
compiler info: clang: 13.0.0 (clang-1300.0.29.30)
libc info: no libc information available
$SHELL (typically, interactive shell): /bin/bash


[Enabled Hooks]

Attachment: fetch_github_with_depth.log
Description: Binary data

Attachment: fetch_github_without_depth.log
Description: Binary data

Attachment: fetch_local_with_depth.log
Description: Binary data

Attachment: fetch_local_without_depth.log
Description: Binary data


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux