Improve distinction between pushed and unpushed commits

[mjcarman]

Is your feature request related to a problem? Please describe.

In the commit history pane, the green/yellow/red coloration doesn't provide a clear distinction between pushed vs. unpushed commits until after a branch has been pushed for the first time. Yellow is ambiguous. This makes it harder to determine whether I need to push and the commits for which I can safely rewrite history.

Functionally, I'd like to have distinct indications for "on main [Y/N]" and "pushed to remote [Y/N]."

Describe the solution you'd like

I don't have a particular preference but I can think of some options:

• Regular vs. bright colors: this might be too subtle and some themes use the same color for both variants.
• Regular vs. bold/italic text: Support for bold/italic depends on the terminal. It would be nice to have as an option, though.
• Separate colors for the glyph used to represent a commit and the commit SHA.
• Add a delimiter (e.g. horizontal line) between the pushed and unpushed commits on the branch.
• Add a glyph indicating the location of the remote HEAD.
• Make unpushed (red) a higher priority than not on main (yellow).

Describe alternatives you've considered

None

Additional context

Add any other context or screenshots about the feature request here.

[stefanhaller]

I don't quite understand the request, and I feel there is some misconception about what the colors mean.

Currently, for branches that have an upstream branch the rule is that all commits that are contained in the upstream branch are yellow, and those that are not are red. For branches that don't have an upstream branch, all commits are yellow. In both cases, all commits that are contained in main are green.

You could argue that for branches that have never been pushed, all commits should be red. This would make some sense because those commits are not contained in the upstream (because it doesn't have one). I'm hesitant to make that change though, because it would look very unfamiliar to existing users.

What's your goal here? Do you want to be able to tell by the color of the hashes whether the branch has an upstream or not? This information is available in the branches panel and in the status view (by the presence or absence of either the green checkmark or the yellow arrows), so I'm not sure it needs to be repeated in the commits panel.

[stefanhaller]

You could argue that for branches that have never been pushed, all commits should be red.

I had to think about this more, and depending on what you take the colors to actually mean, this could be the best change, or not.

To elaborate: currently, the meaning of the colors (for a branch with an upstream at least) seems to be "how likely am I to lose my commits if my hard drive dies". Commits on main are green, you don't lose them because they are upstream and in all forks too. Colors that are pushed to your upstream branch are a little less universally available (if your hard drive dies and then you also delete your fork, they are gone, since they are not on any other forks). Unpushed commits are totally lost when your hard drive dies, so they are red. This all makes sense, and if we take this meaning, then commits on a branch that doesn't have an upstream should be red too.

However, the colors could also mean "how good of an idea is it to rewrite this commit (e.g. reword it or move it)?" In that case, main commits should be red of course (absolutely never), pushed commits of a branch that has an upstream should be yellow (it's maybe ok to rewrite these if your team's policy allows it and you tell your co-workers that you force-pushed). Unpushed commits should be green, they can always be rewritten without thinking about it. If we take that meaning, the commits on a branch that doesn't have an upstream should be green too.

Which of these seem more intuitive?

[mjcarman]

I don't quite understand the request, and I feel there is some misconception about what the colors mean.

That's perfectly understandable; I've found interpreting and making use of the colors confusing enough that I had a hard time articulating my problem and an ever harder time coming up with a specific request to remedy it.

Do you want to be able to tell by the color of the hashes whether the branch has an upstream or not?

No. I want to be able to tell which commits have been pushed to upstream. I have a typical workflow which seems reasonable but doesn't mesh well with this behavior of lazygit:

1. I create a branch for an issue, make some changes, then push it to upstream and open a merge request.
2. While the MR is open I start working on another issue; creating a branch and making changes.
3. If the second issue depends on changes from the first issue, I create the second branch from the first branch instead of from main.
4. While working on the second (local only) branch, I rebase and fixup commits to get clean history.
5. When the MR closes, I rebase the second branch on the final version of the first branch (or on main after the merge).
6. Goto (1) for the second branch.

With this workflow, yellow meaning both "has upstream and has been pushed" and "doesn't have upstream, isn't on main" is a constant source of confusion. On the first branch (fixing problems detected in the MR review), the red/yellow distinction is great. On the second branch (local WIP), all of my commits (other than those on main, of course) are yellow.

[C]urrently, the meaning of the colors (for a branch with an upstream at least) seems to be "how likely am I to lose my commits if my hard drive dies".

I can see value in that but it's not a question I've needed answered — certainly not as part of my regular workflow. git reflog has enabled me to fix mistakes that might have otherwise required the nuclear option.

[T]he colors could also mean "how good of an idea is it to rewrite this commit (e.g. reword it or move it)?"

This is pretty much what I want. (As a configuration option, obviously.) As the two color schemes are basically opposites, you could reduce potential confusing somewhat by using different colors for the second mode. e.g. red for commits which haven't been pushed to upstream, blue ("frozen") for commits which are on main, and magenta (a mix of blue and red) for commits which are on a branch and have been pushed to upstream.

I don't know how difficult this would be to implement. I realize that it would require lazygit to consider more than just the current branch when determining colors.

[stefanhaller]

Oh I see, it's only about stacked branches. Funny, I use stacked branches quite a lot (sometimes with more than two branches), but I have never noticed this as a problem.

I have to admit that I'm having trouble wrapping my head around this, and deciding what the ideal, desired behavior would even be. If branch2 is sitting on branch1, and is checked out, do you then want to see the colors of the branch1 commits as if branch1 was checked out? I'm not sure if this couldn't be confusing too, in some cases, e.g. if branch2 also has an upstream already (actually this is usually the case for me; I often have PRs for both branches open at the same time). Also, there could be two different branches pointing at the commit that branch1 is pointing at, one if which is diverged from its upstream, the other isn't; which of the two would determine the colors? A bit hypothetical perhaps, but the code needs to be able to deal with this.

For me this has never been an issue because I see that little branch icon (or * if you don't have nerd fonts) for the head of branch1, and I simply don't care about the colors of the commits below that, because I know they don't belong to the current branch.

[mjcarman]

it's only about stacked branches

No, that's only half of it. I find it confusing to use yellow for commits on new branches which haven't been pushed. As you mentioned in your first reply, it would seem more intuitive to me to color those red, though I can see using yellow if the repository (as a whole, not just the branch) doesn't have an upstream.

If branch2 is sitting on branch1, and is checked out, do you then want to see the colors of the branch1 commits as if branch1 was checked out?

Yeah. Conceptually (i.e. from a workflow perspective), I want to treat branches as real things and "a branch is just a pointer to a commit" as an implementation detail. I wouldn't expect git purists to like that, but I don't think it's incompatible with lazygit's ethos of creating a simpler UI around git's plumbing.

if branch2 also has an upstream already

In that situation I'd expect branch2's commits to be a mix of yellow (pushed) and red (local).

there could be two different branches pointing at the commit that branch1 is pointing at

Yeah, and multiple remotes — which I've never used, but is possible.

For me this has never been an issue because I see that little branch icon

Yeah, I figured that out eventually, but it's a bit subtle in the sea of yellow surrounding it.

[stefanhaller]

Ok, so let's talk about the two things separately.

Hash color for branches that don't have an upstream

I tried a build that uses red for these, and couldn't get used to it. It just looks wrong to me. This may well be because I'm simply used to the current color scheme, but also, red to me conveys something like "there's something here that you need to pay attention to". This makes sense if it has an upstream (attention, don't forget to push these commits at some point), but it doesn't for branches that are local-only.

You could also find logical reasons why yellow is ok to use for local-only branches; it depends on how you define the meaning of those colors. Granted, it gets a little philosophical, but:

1. If we define yellow to mean "these are commits that are also on the upstream branch, and everything else is red", then yes, for local-only branches no commit can be yellow, because there is no upstream branch. It follows that all commits should be red.
2. If, however, you define red to mean "these are commits that haven't been pushed to the upstream branch, and everything else is yellow", then this is a category that isn't applicable to local-only branches, because there is no upstream branch; so no commit can be red in that case.

Oh, and I also tried a build that goes further and also swaps green and red for "on main" and "unpushed", and I totally couldn't get used to that at all, so I'm not considering that as an option.

Coloring stacks of branches

Conceptually (i.e. from a workflow perspective), I want to treat branches as real things

I can understand this, but I'm still hesitant it's a good idea to pretend that they are. We would have to rely on the assumption that a constellation like in the example above always constitutes a stack of branches, and I'm not sure it always is for all people. Just one example (contrived? I'm not sure): suppose I use only branch2 to collaborate with my colleagues. Only branch2 has a PR attached to it, and its base branch is main. branch1 is an unpushed branch that I only use as a marker locally, e.g. to better see where my backend changes end and the frontend changes start (or whatever). Based on your proposal, the commits up to the head of branch1 would be red, and the commits from then on would be yellow or red depending on branch2's upstream. I would find this highly confusing in this scenario.

Granted, for this particular case we could improve it by saying that we only consider branch1's colors if it has an upstream, and use branch2's colors if not. I'm just worried that we and up with a complex system of heuristics that is hard to understand (both for users and for future developers). The current system at least has the advantage that it is very simple.

And of course, another reason why I'm reluctant to add logic like this is that it makes lazygit slower (we'd need additional calls to git merge-base for the other branches in the stack).

but it's a bit subtle in the sea of yellow surrounding it.

Maybe we're getting to the actual problem here? That branches in a stack aren't clearly enough separated from each other, visually? I'm not a skilled UI designer, so if you have suggestions for improving this, I'm all ears. If there was a way to draw a horizontal divider line without it taking up vertical space, I'd be totally up for that, but I don't see a way of doing that in a TUI app, and sacrificing a blank row just for a divider doesn't seem worth it to me.

[mjcarman]

Ok, so let's talk about the two things separately.
Hash color for branches that don't have an upstream
Coloring stacks of branches

The most intuitive thing to me would be for "has upstream" to be evaluated at the repository level rather than the branch level.

For repos without an upstream (e.g. created via git init and never pushed anywhere):

• green: commit exists on main
• yellow: commit only exists on a branch

For repos with an upstream (e.g. created via git clone):

• red: commit only exists in the local repo
• yellow: commit exists on upstream remote branch
• green: commit exists on upstream remote main

Ideally this would "just work" with stacked branches, but I understand that might not be possible, simple, and/or performant.

[red meaning "pay attention"]
This makes sense if it has an upstream (attention, don't forget to push these commits at some point), but it doesn't for branches that are local-only.

This is where we disagree philosophically and it's probably the core problem. If I create a local branch, I almost always intend to push it at some point. Showing commits to it in yellow gives the impression that I already have. While I'd like stacked branches to work the way I described above, it's the ambiguity of yellow that really bothers me. I'd probably be content if lazygit used different colors for:

• commits on a branch that doesn't have an upstream
• unpushed commits on a branch that has an upstream
• pushed commits on a branch that has an upstream

and ignored the complexities of stacked branches, peer-to-peer remotes, etc. entirely.

To reduce this all to a simple request: Please use cyan instead of yellow for commits to a branch that doesn't have an upstream.

Alternately, add config options for (separately) configuring commit colors for branches with/without an upstream.

I'm not a skilled UI designer

Ha! Me neither. I just copy things that seem to work well in other tools (which presumably do have skilled UI designers). :)

Whatever comes out of this request, thank you very much for taking the time and effort to give it serious consideration!

[stefanhaller]

Please use cyan instead of yellow for commits to a branch that doesn't have an upstream.

This makes sense to me, and who knows, maybe I'll even like it myself. I'll try this when I get home and see if I can get used to it.

Since I'm on vacation right now, this won't happen before November.