When debugging a complex Git rebase, the default logs are rarely enough. By enabling Git rebase debug logging access, you can inspect the exact commands, applied patches, and decision points that occur during replay. This visibility turns guesswork into certainty.
Start by running:
GIT_TRACE=1 GIT_TRACE_SETUP=1 GIT_TRACE_PACK_ACCESS=1 GIT_TRACE_PACKET=1 \
GIT_TRACE_PERFORMANCE=1 git rebase <branch>
These environment variables unlock detailed trace output. You will see every internal step, from reading refs to applying commits. For even deeper analysis, set GIT_DEBUG_REBASE=1 before executing the rebase. This generates verbose debug logs in .git/rebase-merge or .git/rebase-apply, depending on the mode.
Key debug files to check:
- git-rebase-todo: ordered list of pending commits and actions.
- patch: the current commit patch being applied.
- msg-clean: the normalized commit message after processing.
- done: commits already applied during this rebase session.
By inspecting these logs in real time, you can pinpoint why a conflict occurred, confirm commit sequencing, and validate that resolved changes match intent before continuing with git rebase --continue.
For automated or collaborative debugging, print and store these logs in your CI/CD pipeline. They can be parsed to detect patterns, like recurring conflict files or performance bottlenecks during rebases on large repos.
Git rebase debug logging access is not just about fixing a broken rebase—it’s about gaining full control over what Git is doing under the hood, step by step.
Want to explore this kind of deep-level Git visibility without scripting it yourself? Check out hoop.dev and see it live in minutes.