@jesseduffield I'd be interested in your thoughts on this. The branch conflicts pretty heavily with other work that I have open, so it's going to be painful to carry it around for longer.

@stefanhaller I intend to get around to this: but have yet to find the time to properly read through the issue

Looking at this from a visual perspective, It's definitely better than before (less noisy for my use case), but looking at the following screenshot:

I feel like I'd want to see some context as to which head/branch is at this point. As someone who basically never switches to the full git graph view, it would be nice to see it on the right pane in the header details for the commit, similar to how it's already displayed when viewing a branch directly:

I agree, and it does do that for me. I'm using the delta pager, which seems to add this information. I was a bit surprised to see that, I didn't actually know this would be possible, as I thought the pager was purely a post-processor; but I don't see any other config setting that could be responsible for this.

Give it a try, delta is awesome anyway. 😄

I tried using the delta pager in the past, but it results in broken displays which are very hard to read so don't see that as an option:

As for delta: it can be configured pretty heavily, you might try to tone it down a bit to make it less noisy. My own preferred configuration is (this goes in ~/.gitconfig:

[delta]
	syntax-theme = none
	file-decoration-style = yellow ol
	file-style = yellow bold
	hunk-header-decoration-style = blue
	hunk-header-style = file normal
	hunk-header-decoration-style = ol ul magenta
	hunk-header-file-style = blue
	minus-style = normal "#660000"
	minus-emph-style = normal "#aa1111"
	plus-style = normal "#004400"
	plus-emph-style = normal "#117711"
	line-numbers = true

The main reason why I use delta is the word highlighting which shows which parts of a line have changed. I wouldn't want to live without this any more.

As for the branch annotation though: I'm very confused about this. When I run lazygit without delta, I don't see it, but when I type git show on the command line (which is what lazygit uses to render the display), I do. Can anybody explain this?

Hm, it looks like git bases the decision whether or not to show the branch annotation on whether output goes to a tty; I don't see a git option to influence this. So if you don't like delta, a very crude workaround is to set your pager to cat. 😄

git:
  paging:
    pager: cat

I still don't fully understand it, I wonder if it's a bug in git.

Hm, it looks like git bases the decision whether or not to show the branch annotation on whether output goes to a tty; I don't see a git option to influence this. So if you don't like delta, a very crude workaround is to set your pager to cat. 😄

This works great. I do wonder if this should be default for lazygit.

I read the git source code a bit, and found that it's intentional to show ref names when the output is a tty, and don't show them if not. This corresponds to the --decorate=auto option of git log. This means that another workaround is to do git config --global log.decorate short, which git show respects too.

For lazygit, the best fix is to pass --decorate to git show. I'll make a PR.

PR is here: #2748

Actually something that just occurred to me that could vastly simplify this: we now obtain commit hashes when we load local branches. We could use those when displaying the commits. That would spare much of the complexity of the current solution. That is: in the presentation package, when displaying commits, we pass in branch commit hashes and if a given commit matches the hash, we show the marker. The only extra thing is that we'd need to refresh the commits view after loading branches (trivially easy to do)

Actually something that just occurred to me that could vastly simplify this: we now obtain commit hashes when we load local branches. We could use those when displaying the commits.

That's a great idea, I'm trying this right now, and indeed it greatly simplifies things.

One thing that I'm not sure how to do: I need to read .git/rebase-merge/head-name in order to find out whether a commit points to the head of the branch that is currently being rebased (we don't want to show the marker for this one). In the previous version of the PR I did it like this. Now I need the same thing in GetCommitListDisplayStrings (or at the call site and pass it in), but I can't figure out how to get at dotGitDir there. But I have the feeling I shouldn't be loading files at that place in the code anyway, but rather have a function somewhere that does this. Any suggestions where this would go?

I agree that we should obtain that info ahead of time to keep the presentation code pure. I'm happy to add the merge head as a field on our Model struct and set that from RefreshHelper (perhaps as part of loading branches or loading commits, or as its own separate thing).

Since the new approach is quite different from this one, I'm opening a new PR for it: #2775.