feat(log): commit trees + local/all branches + all refs

[cjordan]

Greetings,

This PR adds commit trees to the log view, as well as the ability to view all local branches, all branches, or all refs. Screenshot of a snippet of gitu's history:

Excluding src/git/tree.rs (a new file) and tests, the scope of the changes is small. At this point, I happily admit this PR is LLM-assisted - I used Qwen3.8-27b locally. I've heavily scrutinised all changes except past line 190 of src/git/tree.rs, which is where my eyes glaze over from the rendering logic. However, I did manage to tighten up a bunch of the LLM-generated code after steering it toward a "readable"/"simple"/"maintainable" goal. With all that said, I'll happily respect your wishes if you don't want this contribution due to AI.

Otherwise, please let me know what more I can do. I've been (extremely slowly) trying to get these tree views working for over 2 years now; it's something I can't live without, so it'd be great to see it gitu and I'm one step closer to leaving magit.

[cjordan]

ehhhh Of course, I found an edge case after making the PR (as well as failing the CI for a silly fmt error).

For some reason I found that the tree of https://github.com/shizunge/endlessh-go looks different between my gitu branch and magit.

magit (log current/local branches/all branches/all references)

my gitu PR branch (log current/local branches)

my gitu PR branch (log all branches/all references)

So the PR's branch logic is clearly not completely wrong, but it's inconsistent with magit (and git log --graph). A little tweaking does resolve the inconsistency, but I think this raises a question. Given that my example only has 1 branch, I don't expect to see multiple branch lines, so I kinda like the original PR's behaviour. But I also think that most people would expect gitu to be consistent with magit and git.

Soon, I'll post a follow-up commit to this PR branch to fix the inconsistency, but leave the choice to you, dear maintainer.

[altsem]

edit: should log current list merged commits? I'm unsure what is expected here (maybe master is broken? I rarely work with merges myself anymore).

Don't see an issue with the graphs looking slightly different, they still mean the same, right?

[cjordan]

Thanks for your fast reply, and sorry for my slow response (blame my kids) and the confusion. I don't think anything is wrong with gitu's master branch.

I think what needs to be decided is a matter of taste. In this current PR's code, log current/local branches gives a (flat) view that is different to git log --graph --oneline main and magit's log current/local branches view. I personally prefer it; the extra lines are just noise to me, but the tradeoff is a view that users might not expect. The information presented is accurate and correct (AFAICT).

It's easy to modify gitu's views in this PR to match the others for consistency. Just let me know if you think that's worth it or not.

Also, if you care to analyse these differences, there's also a git discrepancy when sorting commits -- here's a message from my LLM assistant (in the context of the endlessh-go repo):

One caveat worth knowing: this repo has heavy same-day commit bursts (dozens of dependabot merges all dated 2024-10-07, etc.), so the interleaving of equal-dated commits can differ slightly between libgit2's date heap and git's — e.g. git shows the 139 bump immediately under merge 139, while we show merge 138 first. The structure is complete
and the layout is a valid git log --graph rendering of our (topological, date-ordered) walk; only the tie order among equal timestamps differs. This is the known equal-date heap caveat from earlier, not a defect.

[cjordan]

ah, now that I'm experiementing with gitu's rebasing behaviour, I see the issue now - the extra lines are merges, so rebasing doesn't work well across them, hence it's kinda important to see them (i.e. my flat view hides detail). I'll fix this...