How can I know how much percentage of git push is complete?

I’m pushing a code of around 200 MB into a repo. It is taking a lot of time. Is there anyway we can display the progress bar, so that I can know how much amount of code is pushed into the repo?

  • Getting rid of “git: /usr/local/lib/ no version information available (required by git)”
  • Switching branches prompts to save file
  • Stripped commits on GIT repository with Bitbucket
  • Using passworded git in cruisecontrol.NET
  • Separating a feature into a new branch in Git
  • Why the combination of Maven with Git?
  • Remove a file from git repository, but stash it
  • stop git merge from opening text editor
  • GIT don't push my files
  • Which files of a libGDX HTML project belong into the repository?
  • Delete forked repo from GitHub
  • Is there any way to semi-automatically commit?
  • 2 Solutions collect form web for “How can I know how much percentage of git push is complete?”

    It’s not a progress “bar”, but git push already reports progress by default when it’s run from a terminal. From the official Linux kernel git documentation for git push:


    Progress status is reported on the standard error stream by default when it is attached to a terminal, unless -q is specified. This flag forces progress status even if the standard error stream is not directed to a terminal.

    The fact that you’re trying to push 200 MB at once suggests that you might be doing something sub-optimally with git.

    git push --progress will be more precise with Git 2.10 (Q3 2016)

    See commit e376f17 from Jeff King (peff)

    The index-pack command has two progress meters:

    • one for “receiving objects”, and
    • one for “resolving deltas”.

    You get neither by default, or both with “-v“.

    But for a push through receive-pack, we would want only the “resolving deltas” phase, not the “receiving objects” progress.
    There are two reasons for this:

    • One is simply that existing clients are already printing “writing objects” progress at the same time.
      Arguably “receiving” from the far end is more useful, because it tells you what has actually gotten there, as opposed to what might be stuck in a buffer somewhere between the client and server. But that would require a protocol extension to tell clients not to print their progress. Possible, but
      complexity for little gain.

    • The second reason is much more important.
      In a full-duplex connection like git-over-ssh, we can print progress while
      the pack is incoming, and it will immediately get to the client.
      But for a half-duplex connection like git-over-http, we should not say anything until we have received the full request.
      Anything we write is subject to being stuck in a buffer by the webserver. Worse, we can end up in a deadlock if that buffer fills up.

    So our best bet is to avoid writing anything that isn’t a
    small fixed size until we’ve received the full pack

    Update September 2016: Git 2.10 is there, and you can see an example of this progress meter at the GitHub blog post “Git 2.10 has been released“:

    Update Git 2.11 (Q4 2016)

    Now, an incoming “git push” that attempts to push too many bytes can now
    be rejected by setting a new configuration variable at the receiving

    See commit c08db5a, commit 411481b (24 Aug 2016) by Jeff King (peff).
    See commit 5ad2186 (24 Aug 2016) by Christian Couder (chriscool).
    (Merged by Junio C Hamano — gitster — in commit da3b6f0, 09 Sep 2016)

    receive-pack: allow a maximum input size to be specified

    Receive-pack feeds its input to either index-pack or unpack-objects, which will happily accept as many bytes as a sender is willing to provide.
    Let’s allow an arbitrary cutoff point where we will stop writing bytes to disk.

    git config doc now includes:


    If the size of the incoming pack stream is larger than this limit, then git-receive-pack will error out, instead of accepting the pack file.
    If not set or set to 0, then the size is unlimited.

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