showWholeGraph: true not working or config not used

[domsl]

Hi, i am trying to switch to lazygit and I have troubles getting my workflow right.

One of the things that confuses me: I do not see other branches that are further ahead (lets say feature ahead of main) while having checked out the main branch. Coming from gitextensions this is second nature, but I do enjoy the speed and terminal experience of lazygit.

So I tried to enable showWholeGraph

Describe the bug

I've added

  log:
    # displays the whole git graph by default in the commits view (equivalent to
    # passing the `--all` argument to `git log`)
    showWholeGraph: true

to my config file (C:\Users\abc\AppData\Local\lazygit)

But the panel 4 does not show me my "ahead" branch while I checked out the the branch further back.

<C-l> and "Toggle to show git-graph (pass --all)" does what I want, so I tried to enable it by default and failed.

To Reproduce

Steps to reproduce the behavior:

1. Add yml above to
2. Open lazygit and checkout a graph further behind

Expected behavior

See newer commits from other branches

Screenshots

Version info:

lazygit --version commit=80223c7fbbd0b86631a988834cbe88e267bb0bd9, build date=2025-11-01T09:43:19Z, build source=binaryRelease, version=0.56.0, os=windows, arch=amd64, git version=2.50.1.windows.1

Terminal info:

Windows Terminal with Command Prompt

Additional context

Additionally I have a question:

In the screenshot, is on (All enabled), but the top four commits are actually from a different branch, which isn’t visible in the log. Is there a way to show that?

When I maximize (++), it shows up, so I’m wondering if there’s an option to color it differently or use different dots or something. Any visual cue that makes it obvious it’s a different branch?

edit:

I could just reproduce the same behaviour on Fedora on Ptyxis - so maybe I am misunderstanding the config?

[stefanhaller]

You are missing the git: in the config. It's

git:
  log:
    showWholeGraph: true

When editing the config file I recommend to use a YML language server that supports the JSON schema store (in VS Code that would be Redhead's YAML extension), this way you get inline error reporting for cases like this, and auto-completion.

That said, I'm afraid I have to advise against using the showWholeGraph feature at this point. It is broken in many ways, see #3608 and #4997 (and there are probably even more problems that aren't even mentioned in those issues). There is an open PR that attempts to fix those, but I'm not convinced it uses the right approach, and I have never gotten around to having a closer look at it. I was often tempted to remove the feature until we have a chance to reimplement it properly.

It doesn't have high priority for me though because I personally don't find the feature useful. There are other git clients that use the --all view by default (e.g. Sublime Merge), and I hate it and always need to search for the feature to restrict the log to the current branch. (I realize that this is probably a matter of personal taste.)

As a workaround, you might experiment with the all branches log in the status panel (press 1 a to see it). I know it's not the same because it's not interactive, but maybe this could be a better-than-nothing solution for now. You can customize the log using (for example):

git:
  allBranchesLogCmds:
    - git log --graph --all --color=always --abbrev-commit --decorate --oneline --

[domsl]

You are missing the git:

Yes, of course🤦

I actually fixed the extra spaces to convert it to valid .yml, not noticing it is one level in, as there are a lot of options under git:.

Thank you!

It is broken in many ways
That is good to know, I will avoid it then.

allBranchesLogCmds:
- git log --graph --all --color=always --abbrev-commit --decorate --oneline

That is a good quite good to know, thank you!

It doesn't have high priority for me though because I personally don't find the feature useful. There are other git clients that use the --all view by default (e.g. Sublime Merge), and I hate it and always need to search for the feature to restrict the log to the current branch. (I realize that this is probably a matter of personal taste.)

That makes me curious- why is that?

Whats your workflow when you want to, let's say, merge the feature branch into main? You just switch to main, knowing the feature is there and then select feature->merge?

Because I always want to see / check where my feature branch is in relation to main?

[stefanhaller]

It doesn't have high priority for me though because I personally don't find the feature useful. There are other git clients that use the --all view by default (e.g. Sublime Merge), and I hate it and always need to search for the feature to restrict the log to the current branch. (I realize that this is probably a matter of personal taste.)

That makes me curious- why is that?

I want to focus on one branch at a time. Seeing multiple branches at once is too noisy and visually overwhelming for my taste (unless they are stacked on top of each other, that is).

Whats your workflow when you want to, let's say, merge the feature branch into main?

I press the Merge button in Github. 😄

If I were to merge branches manually, then yes, I'd checkout main, select the feature branch in the branches panel, and hit M.

Because I always want to see / check where my feature branch is in relation to main?

Is that because you want to see whether your branch has fallen behind main, and you maybe want to rebase it first before merging? (We do this both at work and here in the lazygit repo to get a cleaner git history.) In that case you might like the following config, which shows this information for every branch in the branches panel:

gui:
  showDivergenceFromBaseBranch: arrowAndNumber

[domsl]

Seeing multiple branches at once is too noisy and visually overwhelming for my taste

Yeah, I can relate.

I press the Merge button in Github. 😄

I see :D
Yeah I do a lot of merging locally because of either small projects (where I can merge and push to main) or for example in Kicad libraries where there is alot of things going on and I need to carefully merge the always developing upstream branch (and merging is difficult with CAD files)

Is that because you want to see whether your branch has fallen behind main, and you maybe want to rebase it first before merging?

Exactly. I just want to see the relations so showDivergenceFromBaseBranch is very good. So I can be like "oh we are way behind, let me open up the log with all enabled to see if an easy merge is possible"

Can I also enable it in both directions? Because for example here the main branch is 4 commits behind of feature, so I would expect something like ↑4, or am I misunderstanding? (Or if main is checked out an ↓4 for being behind feature?)

[stefanhaller]

Can I also enable it in both directions? Because for example here the main branch is 4 commits behind of feature, so I would expect something like ↑4, or am I misunderstanding?

No, these numbers have nothing to do with what's checked out. They only display the divergence of each branch from its main branch. Main doesn't show one because it is the main branch.

When I added the feature, I initially considered showing the full diversion (e.g. ↓7↑4) instead of just the "behind" numbers, but decided against it because I thought it's too much visual noise, and unnecessary. The ↑4 would basically just indicate the length of the branch, which I thought is not so relevant to know.

[domsl]

I see. Thank you for taking time to explain all of the above. I really appreciate. :)