Git Troubleshooting for Slow or Hanging Commands: Tracing, Verbose Logs, and Safer Diagnostics

Originally published on 2014-08-18; fully revised and updated.

If Git commands like clone or push seem slow, stuck, or silent, enabling Git’s built-in tracing is often the fastest way to see what is happening. This guide is for developers and DevOps engineers who need a repeatable way to collect useful diagnostics and narrow down whether the issue is local config, network transport, or remote server behavior.

Quick triage workflow for hanging Git commands

Use this sequence when a Git operation appears hung. It helps you capture diagnostics first, then make targeted changes.

flowchart TD
    A[Git command is slow or appears stuck] --> B[Re run with trace enabled]
    B --> C[If HTTP or HTTPS remote add curl verbose]
    C --> D[Capture output to a log file]
    D --> E[Check remote URL auth and Git config]
    E --> F{Issue resolved}
    F -- Yes --> G[Run normally and remove debug vars]
    F -- No --> H[Check network server and repo factors]
    H --> I[Share logs with Git or platform admin]

Debug options and what each one is for

Practical command patterns

The original post listed several useful snippets. The examples below normalize them into copy-paste-safe commands with standard double-dash flags.

# One-off trace for a clone
GIT_TRACE=1 git clone <repository-url>

# Verbose push with HTTP diagnostics
GIT_CURL_VERBOSE=1 git push -u origin --all --verbose

# Capture detailed push output to a file
GIT_TRACE=1 GIT_CURL_VERBOSE=1 git push --verbose 2>&1 | tee git-debug.logCode language: PHP (php)

# Set for current shell session
export GIT_CURL_VERBOSE=1
git push

# Remove when done
unset GIT_CURL_VERBOSECode language: PHP (php)

# Inspect active Git configuration
git config --list

# Check whether this global key is set
git config --global --get http.postBufferCode language: PHP (php)

What to check before changing Git settings

• Verify the remote URL and protocol with git remote -v.
• Reproduce the issue once with tracing enabled and save logs.
• Confirm whether the issue affects only one repository or multiple repositories.
• Check whether the problem is specific to HTTP/HTTPS transport or SSH transport.
• Avoid persistent config changes until diagnostics show a clear cause.

Original reference links

These links were included in the original article and are preserved for further reading:

• https://github.com/gitlabhq/gitlab-public-wiki/wiki/Trouble-Shooting-Guide
• https://drupal.org/node/1065850
• http://mattberther.com/2013/12/29/pushing-large-git-repos-with-ssh
• http://ocaoimh.ie/2008/12/10/how-to-fix-ssh-timeout-problems/
• http://unix.stackexchange.com/questions/3026/what-do-the-options-serveraliveinterval-and-clientaliveinterval-in-sshd-conf

Common pitfalls

• Using typographic dashes (–) instead of standard CLI dashes (--), which breaks commands.
• Leaving debug environment variables enabled after troubleshooting.
• Tweaking http.postBuffer without collecting trace logs first.
• Troubleshooting from memory instead of sharing captured output with your Git platform admin.

Rajesh Kumar

I’m Rajesh Kumar, a DevOps, SRE, DevSecOps, Cloud, and Platform Engineering expert passionate about sharing practical knowledge, real-world experiences, and industry best practices. I have worked at Cotocus and regularly write about technology, travel, investing, health, product reviews, and digital marketing through my various platforms.

I publish technical articles at DevOps School, travel stories at Holiday Landmark, stock market insights at Stocks Mantra, health and fitness guidance at My Medic Plus, product reviews at TrueReviewNow, and SEO and digital marketing strategies at Wizbrand.