Mercurial Debug Logging: How to See Everything and Fix Issues Faster

The log file grows like a shadow. Every commit, every pull, every push—Mercurial records it all. But when a bug hides deep in the workflow, you need Mercurial debug logging access to see everything the system sees. Without it, you’re guessing. With it, you’re in control.

Mercurial’s debug logging mode exposes the internal commands, network calls, and repository state in real time. It is the fastest way to pinpoint broken hooks, misfiring extensions, or slow operations. Enabling it is straightforward, but knowing exactly where and how to read it is the difference between a fix in minutes or a lost day.

To enable Mercurial debug logging, use:

hg --debug <command>

For example:

hg --debug pull

This outputs every step of the pull process—HTTP requests, bundle details, manifest processing, changeset application. If your repository uses custom extensions, debug mode logs their execution flow, argument parsing, and side effects.

Advanced setups often redirect this output to a file for review:

hg --debug pull > debug.log 2>&1

From there, grep for keywords—hook names, function calls, transaction IDs—to find anomalies fast. You can reproduce the bug and compare multiple runs. Mercurial’s debug logging can also be enabled persistently by adding to your .hgrc or mercurial.ini config:

[ui]
debug = true

Persistent debug mode is useful on staging systems or during live migrations. Just remember to disable it when done, as debug logs grow large and may contain sensitive data such as URLs or credentials passed to extensions.

The key to effective Mercurial debug logging access is narrowing the noise. Focus on specific commands and run them in isolation. If your goal is to track network performance, test fetches and pushes with minimal file changes. If your goal is to trace hook failures, debug the exact triggering event. Faster analysis comes from targeted logging, not endless scrolls through output.

Mercurial doesn’t guess. It tells you exactly what it’s doing. Debug logging gives you the whole story—raw, unfiltered, and timestamped. The rest is knowing how to read the signals from the storm.

Run it now. See the output. Watch the patterns. Then fix what’s broken. Try it live in minutes with hoop.dev.