what is git-remote-http prcess, why there are so many git processes?

i cannot find git-remote-http command in shell, why there is such process?

i only opened one git svn process, why there are so many git related processes?

[mirror@home git]$ pgrep git
[mirror@home git]$ pgrep git -lf
12035 git fetch origin
12036 git-remote-http origin http://git.savannah.gnu.org/r/weechat.git/
22308 git svn clone http://code.taobao.org/svn/obconnector/
22309 /usr/bin/perl /home/mirror/ins_git/libexec/git-core/git-svn clone http://xxx.org/svn/xxx/
22394 git update-index -z --index-info
22397 git hash-object -w --stdin-paths --no-filters
24128 git fetch origin
24129 git-remote-http origin http://git.xxx.org/xxx.git/
26136 git fetch origin
26137 git-remote-http origin http://git.xxx.org/xxx.git/ 

  • Running a git command with wildcard works in bash but not through Process
  • Visual Studio 2013 Update 3 Process taking up 30% CPU for a long time after commit
  • Process leaked file descriptors error on JENKINS
  • Does ClearCase fit our development process?
  • Apparently nondeterministic behavior in this code calling out to an external process
  • Should you check in your compiled assets to Git?
  • Which signals can safely be used to kill a Git process and which not?
  • Export files from git revision with Process()
  • 2 Solutions collect form web for “what is git-remote-http prcess, why there are so many git processes?”

    One separate process for each http request.
    There are many clients requesting the service so there are many git processes.

    It is called a remote helper

    they are invoked by git when it needs to interact with remote repositories git does not support natively.
    A given helper will implement a subset of the capabilities documented here.

    When git needs to interact with a repository using a remote helper, it
    spawns the helper as an independent process
    , sends commands to the helper’s standard input, and expects results from the helper’s standard output.

    Note that until Git 2.11 (Q4 2016), a “git fetch http::/site/path” (which is an invalid url) would not die correctly and would segfault instead.

    See commit d63ed6e (08 Sep 2016) by Jeff King (peff).
    (Merged by Junio C Hamano — gitster — in commit c13f458, 15 Sep 2016)

    remote-curl: handle URLs without protocol

    Generally remote-curl would never see a URL that did not have “proto:” at the beginning, as that is what tells git to run the “git-remote-proto” helper (and git-remote-http, etc, are aliases for git-remote-curl).

    However, the special syntax “proto::something” will run git-remote-proto with only “something” as the URL.
    So a malformed URL like:


    will feed the URL “/example.com/repo.git” to git-remote-http.
    The resulting URL has no protocol, but the code added by 372370f (http: use credential API to handle proxy authentication, 2016-01-26) does not handle this case and segfaults.

    Git 2.13 (Q2 2017) expand on that by making sure the “smart HTTP” remote
    helper understands what to do with the “--push-options” passed through the
    external remote helper interface.

    See commit 511155d, commit eb7b974 (22 Mar 2017) by Brandon Williams (mbrandonw).
    (Merged by Junio C Hamano — gitster — in commit 4e87565, 27 Mar 2017)

    The remote-http process now can receive options, because git send-pack has:


    Pass the specified string as a push option for consumption by hooks on the server side. If the server doesn’t support push options, error out.

    Git 2.14 does enforce the push option verification.

    See commit cbaf82c (09 May 2017), and commit b7b744f (08 May 2017) by Jonathan Tan (jhowtan).
    (Merged by Junio C Hamano — gitster — in commit 3c98008, 23 May 2017)

    The receive-pack program now makes sure that the push certificate
    records the same set of push options used for pushing.

    Git Baby is a git and github fan, let's start git clone.