git@vger.kernel.org list mirror (unofficial, one of many)
 help / color / Atom feed
* Performance regression on git fetch in 2.21
@ 2019-05-24  9:14 Orgad Shaneh
  2019-06-10 13:55 ` Orgad Shaneh
  0 siblings, 1 reply; 2+ messages in thread
From: Orgad Shaneh @ 2019-05-24  9:14 UTC (permalink / raw)
  To: git, Stefan Beller

Hi,

git fetch in my repository *when nothing new is received* takes 2.5x
the time when comparing 2.20 against 2.21 (on Windows it's 4x).

I have 5 initialized submodules in this working directory.

I reported this issue on git-for-windows github:
https://github.com/git-for-windows/git/issues/2199 but there is also
an upstream change related.

I bisected and found this commit to blame:

Building... Fetching... Failed [10.7949124]
Bisecting: 0 revisions left to test after this (roughly 0 steps)
[a62387b3fc9f5aeeb04a2db278121d33a9caafa7] submodule.c: fetch in
submodules git directory instead of in worktree
running git-bisect.rb
Building... Fetching... Success [4.303592]
be76c2128234d94b47f7087152ee55d08bb65d88 is the first bad commit
commit be76c2128234d94b47f7087152ee55d08bb65d88
Author: Stefan Beller <sbeller@google.com>
Date:   Thu Dec 6 13:26:55 2018 -0800

    fetch: ensure submodule objects fetched

    Currently when git-fetch is asked to recurse into submodules, it dispatches
    a plain "git-fetch -C <submodule-dir>" (with some submodule related options
    such as prefix and recusing strategy, but) without any information of the
    remote or the tip that should be fetched.

    But this default fetch is not sufficient, as a newly fetched commit in
    the superproject could point to a commit in the submodule that is not
    in the default refspec. This is common in workflows like Gerrit's.
    When fetching a Gerrit change under review (from refs/changes/??), the
    commits in that change likely point to submodule commits that have not
    been merged to a branch yet.

    Fetch a submodule object by id if the object that the superproject
    points to, cannot be found. For now this object is fetched from the
    'origin' remote as we defer getting the default remote to a later patch.

    A list of new submodule commits are already generated in certain
    conditions (by check_for_new_submodule_commits()); this new feature
    invokes that function in more situations.

    The submodule checks were done only when a ref in the superproject
    changed, these checks were extended to also be performed when fetching
    into FETCH_HEAD for completeness, and add a test for that too.

    Signed-off-by: Stefan Beller <sbeller@google.com>
    Signed-off-by: Junio C Hamano <gitster@pobox.com>

:040000 040000 2bad86c248b79ef1e36ea5edaa423cd73445c9a2
ad989a8f3e6f80d4f5a84ec3db0ff1ab00a7e210 M      builtin
:100644 100644 d1b6646f42d5d12740a94f50a7d25aad4aa356bf
b88343d977d78364b417e2015eaa352dec1501b9 M      submodule.c
:040000 040000 a3c58919de0796b6467709a0f21fa21e28d4d13b
cdf9514c9085efcbfcdba8efc765174f6455ce5d M      t

Can you please suggest a fix? Is this the expected behavior?

Thanks,
- Orgad

^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: Performance regression on git fetch in 2.21
  2019-05-24  9:14 Performance regression on git fetch in 2.21 Orgad Shaneh
@ 2019-06-10 13:55 ` Orgad Shaneh
  0 siblings, 0 replies; 2+ messages in thread
From: Orgad Shaneh @ 2019-06-10 13:55 UTC (permalink / raw)
  To: git

On Fri, May 24, 2019 at 12:14 PM Orgad Shaneh <orgads@gmail.com> wrote:
>
> Hi,
>
> git fetch in my repository *when nothing new is received* takes 2.5x
> the time when comparing 2.20 against 2.21 (on Windows it's 4x).
>
> I have 5 initialized submodules in this working directory.
>
> I reported this issue on git-for-windows github:
> https://github.com/git-for-windows/git/issues/2199 but there is also
> an upstream change related.
>
> I bisected and found this commit to blame:
>
> Building... Fetching... Failed [10.7949124]
> Bisecting: 0 revisions left to test after this (roughly 0 steps)
> [a62387b3fc9f5aeeb04a2db278121d33a9caafa7] submodule.c: fetch in
> submodules git directory instead of in worktree
> running git-bisect.rb
> Building... Fetching... Success [4.303592]
> be76c2128234d94b47f7087152ee55d08bb65d88 is the first bad commit
> commit be76c2128234d94b47f7087152ee55d08bb65d88
> Author: Stefan Beller <sbeller@google.com>
> Date:   Thu Dec 6 13:26:55 2018 -0800
>
>     fetch: ensure submodule objects fetched
>
>     Currently when git-fetch is asked to recurse into submodules, it dispatches
>     a plain "git-fetch -C <submodule-dir>" (with some submodule related options
>     such as prefix and recusing strategy, but) without any information of the
>     remote or the tip that should be fetched.
>
>     But this default fetch is not sufficient, as a newly fetched commit in
>     the superproject could point to a commit in the submodule that is not
>     in the default refspec. This is common in workflows like Gerrit's.
>     When fetching a Gerrit change under review (from refs/changes/??), the
>     commits in that change likely point to submodule commits that have not
>     been merged to a branch yet.
>
>     Fetch a submodule object by id if the object that the superproject
>     points to, cannot be found. For now this object is fetched from the
>     'origin' remote as we defer getting the default remote to a later patch.
>
>     A list of new submodule commits are already generated in certain
>     conditions (by check_for_new_submodule_commits()); this new feature
>     invokes that function in more situations.
>
>     The submodule checks were done only when a ref in the superproject
>     changed, these checks were extended to also be performed when fetching
>     into FETCH_HEAD for completeness, and add a test for that too.
>
>     Signed-off-by: Stefan Beller <sbeller@google.com>
>     Signed-off-by: Junio C Hamano <gitster@pobox.com>
>
> :040000 040000 2bad86c248b79ef1e36ea5edaa423cd73445c9a2
> ad989a8f3e6f80d4f5a84ec3db0ff1ab00a7e210 M      builtin
> :100644 100644 d1b6646f42d5d12740a94f50a7d25aad4aa356bf
> b88343d977d78364b417e2015eaa352dec1501b9 M      submodule.c
> :040000 040000 a3c58919de0796b6467709a0f21fa21e28d4d13b
> cdf9514c9085efcbfcdba8efc765174f6455ce5d M      t
>
> Can you please suggest a fix? Is this the expected behavior?
>
> Thanks,
> - Orgad

ping

- Orgad

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, back to index

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-05-24  9:14 Performance regression on git fetch in 2.21 Orgad Shaneh
2019-06-10 13:55 ` Orgad Shaneh

git@vger.kernel.org list mirror (unofficial, one of many)

Archives are clonable:
	git clone --mirror https://public-inbox.org/git
	git clone --mirror http://ou63pmih66umazou.onion/git
	git clone --mirror http://czquwvybam4bgbro.onion/git
	git clone --mirror http://hjrcffqmbrq6wope.onion/git

Newsgroups are available over NNTP:
	nntp://news.public-inbox.org/inbox.comp.version-control.git
	nntp://ou63pmih66umazou.onion/inbox.comp.version-control.git
	nntp://czquwvybam4bgbro.onion/inbox.comp.version-control.git
	nntp://hjrcffqmbrq6wope.onion/inbox.comp.version-control.git
	nntp://news.gmane.org/gmane.comp.version-control.git

 note: .onion URLs require Tor: https://www.torproject.org/

AGPL code for this site: git clone https://public-inbox.org/ public-inbox