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?
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
Progress status is reported on the standard error stream by default when it is attached to a terminal, unless
-qis 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)
index-packcommand has two progress meters:
- one for “receiving objects”, and
- one for “resolving deltas”.
You get neither by default, or both with “
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 (
See commit 5ad2186 (24 Aug 2016) by Christian Couder (
(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.