Add option to "mute" commits not part of current branch

[basvdlinden]

Describe the feature that you'd like
Add an option that shows visually that a commit is not part of the current branch. E.g. by graying out the commit message.

Only applies when showing multiple branches (or Show All)

Additional context (optional)
Setting e.g.: git-graph.muteOtherBranchCommits

Related to: #138

[mhutchie]

Thanks for making this suggestion! This would definitely be nice to have in Git Graph.

[mhutchie]

@basvdlinden You mentioned that you’ve used this before in other tools. Could you please provide a link to the tool, so I can make sure the behaviour I implement is consistent with it?

[basvdlinden]

Hi, the tool I was refereing to is: https://github.com/gitextensions/gitextensions

While capturing some screen-shots, I realize it doesn't dim the commit message. It makes the branch lines gray. See examples:

A muted commit message could give the same visual hint of what is included in you current branch.

[mhutchie]

Thanks @basvdlinden for the screenshots and extra information!

[mhutchie]

I've added a new Extension Setting git-graph.muteCommitsThatAreNotAncestorsOfHead, that when enabled will display commits that aren't ancestors of the checked-out branch / commit with a muted text color. This will be available in v1.20.0.

If you'd like to use it before the next release, you can download v1.20.0-beta.2, and install it following the instructions provided here.

FYI: See my comment here for my thoughts & information on the possible further extension of this feature request with graph-based emphasis (like gitextensions).

[basvdlinden]

Thanks! I tested the change. It is a very helpfull option to have when dealing with large graphs. So I tested a large graph. I think I found a problem. I found out that the commits are only "muted" when the HEAD commit is in the view. Only after pressing "Loading more Commits" a few times unitl the HEAD is in the view, the not-ancestor-of-head-commits are "muted". Actually all commits should be "muted" if the HEAD is not in the view. It is confusing to see non-muted commits which turn to a muted state when loading more commits. I whould like to rely on the visual cue, so I can simply scrol until a I find a non "muted" commit.

---

About "Emphasize selected branches": It feels tempting to have that feature, but I think the existing branch filter covers all use-cases. This, in combination with muteCommitsThatAreNotAncestorsOfHead, gives me the ability to easily find the information I need. The strength of GitGraph is being able to follow a chain of commits by its color. Giving a gray color to all the non-emphasized branche enables me to follow the emphasized branch in a large graph, having all commits. This use-case is also covered with muteCommitsThatAreNotAncestorsOfHead. I think the "muted" commits is just as easy, with the added benefit that you can still follow all individual branches

[mhutchie]

Commits are only "muted" when the HEAD commit is within the loaded commits by design, as the extension only knows the ancestry information for the loaded commits. If the HEAD is not in the loaded commits, that could be either because:

• The HEAD commit is after the first n loaded commits. (your scenario)
• The HEAD commit is filtered out because it is on a branch that has been filtered out.

Unfortunately there isn't a way to distinguish between these two cases. As an example, if the user switched to view a different branch (that didn't include the HEAD commit), muting every commit:

• Would be incorrect when the HEAD shares a common ancestor with the loaded commits because the extension doesn't know when the two lines of history meet. After the two lines of history meet the commits shouldn't be muted, although they would be if the "mute every" approach was taken.
• "mute every" just makes all the commits harder to read.

When faced with the two options when the HEAD commit is not known, "mute every" or "mute none", I prefer to use the "mute none" approach as it will never incorrectly mute a commit (unlike "mute every"). The worst it could do is just not mute a commit that could have been muted, which would only occur in rare scenarios with large repositories (like the one you're working in). The "mute none" case also favours the most likely scenario to occur by most users. The feedback I got from the users I tested this feature with also thought it was better to "mute none" for these reasons.

If you're working on a large repository and the HEAD is not in the initially loaded commits, I'd suggest you increase the Extension Setting Initial Load Commits so that the HEAD is included. This saves you having to keep pressing "Load More Commits" to find the HEAD, and also gives the extension enough information to correctly mute the ancestry.

I'll add a note to the Extension Setting description to indicate that it will only occur when the HEAD is within the loaded commits. This should hopefully clarify it's behaviour.

[basvdlinden]

This makes sense. I indeed picked an exceptional case (having many commits after the HEAD) to test the behavior.

Adding a note to the Extension Setting description could help others understand the behavior, taking away the confusing for the unlikely case it is.

Thanks for the elaborate argumentation / explanation.

[lmcarreiro]

This helps a lot, thank you for implementing it.

But currently, the muted commits shows the grey color on the font/text color only. Is there any chance to change the lines and circles colors on the graph to grey too?