Log: make branch-line coloring easier to understand [SG-11160]

These are just colors to make reading the revision graph easier. Thin lines indicate unpushed commits. Note, that in Git a branch is just a named pointer to a commit. For a arbitrary commit you can't say in which branch it was created (as in Hg).

I recommend to take such topics to the mailing list.

An OnMouseOver popup would help perhaps.

What should be displayed in the tooltip? IMHO, this request often comes up from users who did not fully understand how Git branches work (in contrast to other VCS they are NOT tied to the commits).

It would nice if commit message line is annotated with the colors of the branches it belongs to. Right now you can deduce that by looking at all branches that have a circle against the corresponding commit, but for complex histories it requires some effort and concentration. It could be done with thin vertical lines of the color of the branch before or after (right-aligned) the commit message. Several vertical lines of different color or one line, but with its segments colored in different colors (branches left-to-right order matches segments top-to-bottom order).

In the above screenshot part which colors of the "commit connector lines" you would use for the message text?

I would say, colors of all the branches incident to the "commit node", but I'm not familiar with the git branches graph to be 100% confident.

I recognize that I still have a lot to learn from Git. When one spend too much time trying to figure-out what those colored bars represent, you have to wonder about their usefulness. In your comment "For a arbitrary commit you can't say in which branch it was created", that is perplexing. When I perform a commit, I certainly know which branch it is done under! Those colored bars follow some kind logic that appear to be related to the lifecycle of a branch.

Of course, when committing there usually is a current branch, but the branch can be set to a different commit or deleted later. The commit itself does not know anything about "its" creating branch.

The colored lines are just there to make reading the graph easier for you, especially if line are crossing. Should we all show in black-white?

Never tried this tool so far, but actually GitKraken uses colored bars to annotate commits in the log view. So at least it's not impossible to implement.

Could you please explain what makes the coloring in GitKraken more useful than in SmartGit or other Git clients?

As I said, I've never tried this tool, but after looking at the screenshots I expect that I will spend some fractions of seconds less figuring out where one feature branch (unmerged to the master, if it simplifies the matter) ends and where the other starts, because I don't have to read the commit messages to understand that.

I understand that it might not work very well for more complex scenarios, but I still think it would be nice to have this visual clue to cover many typical use-cases.

@Thomas, could you greyout a merge commit in default coloring mode? For example like here: https://bitbucket.org/mailchimp/mailchimp-api-python/commits/all

Do you mean the text of the merge commit? Of course, this would be possible, but what problem would this solve?

Those commits are, in general, trash commits. And it is super easy to navigate between tickets/PR(from one grey commit to another).

Next 8.1 preview build will color the merge commits gray and allows to configure this color.

17.0.3 has gray merge commits already. Thanks! But is there a way to customize the color?

The color can be changed with the line

graph.merge.text=#808080

- at least in 17.1 preview.

When switching from "View | Default Coloring" to "View | Branch Coloring", is this more understandable? Do you see some disadvantages compared to the "rainbow" Default Coloring?

Branch coloring does focus on one line but I am not sure what sort of branch history it is supposed to mean. Look at this black line when only the "develop" branch is selected from the list of branches.

The "anchor" seems to be set to the current branch (HEAD) which is not visible right now. You can set it to origin/develop by selecting the first commit and invoking View | Set Anchor Commit.

I removed my vote because I now realise that with Git a commit is not "on a branch".

For example, in the following graph, the "1" commit is not more on branch-A than on branch-B.

The interface Details view correctly state that the commit is "on branches: bra-A, bra-B".

Perhaps it is not the branch line coloring that people find confusing, but rather the layout itself? For comparison, there's a request open for horizontal layout ("Possibility to show the "Log" from left to right"); a comment in that bug shows how Perforce's Revision Graph tackles complicated branching structures using a horizontal layout.

Maybe adding colored rectangle next to branches names would help in some cases...

This won't work. The blue line also is part of v4.93.xx. Also, we only take colors from a quite limited pool, but there can be dozens of branches.

Yes it is...but after a merge...

If I push new commits to branch creatique_1132 the blue line will get extended next to the red line which represents branch v4.93.xx. as in the example below (other repo).

We just want to know which branch is represented by which line and not which branches is contained in which branches... We can already see it when lines move to another line.

The purpose of the Log window is to make the history human readable otherwise we can use a terminal window.

Or using a tooltip with the branch name as suggested Thomas Hansen.

In this simple example this might work, but for others it might fail. I line or a commit does NOT belong to a branch in Git. A Git branch is nothing else than a named pointer to a certain commit.

Imagine you move the mouse over the blue line of the 3rd row from the bottom. It belongs to branch (origin/)v4.93.xx and (origin/)creatique_1132.

Currently, in the commit details view there is a "on branches" info. This could simply be displayed as a tooltip when overring the commit bullet in the commits view...

This would be useless for non-trivial repositories. One of ours is a quite clean one, but we have 4 branches developed in parallel. All get merged back and forth to the master. Hence, every commit of some older commits would show the same branches.

On the screenshot we don't see the top of the history log.

Without scrolling up. Are you able to tell me which branch the red line is associated to ?

This is a good example that shows why users wants a way to quickly/easily know which line is associted to which branch.

According to the commit messages I guess the green line is the branch "(origin/)smartsvn" but not the red one, it would be easier to have a way to get this infos when moving the mouse pointer over the green line or the branch name in the branches tab.

No, it is not possible to detect reliable in what branch the commit was created. The merge comments might be a clue for the one who reads the log. The primary parent for branches also might help. But I have seen more complex repositories (using excessive merging for feature branches) where it was impossible to determine the branch, especially because there was none any more.

SmartGit can highlight the current checkout branch using the Branch Coloring option so you can do it for the existing branches.

Why are you talking about commits ? I'm talking about the drawn lines (the path).

Highlighting the selected branch in the branches tab using colors without having to checkout it could be enough to help identify existing branch in the log window. As you do with the Branch Coloring option....but for all the existing branches not for the current checkout one.

Useless in your use case doesn't mean no-one would use it :)

I do it a lot, and having to select each commit to see the branches it belongs to in its details is a pain...

That would be a good workaround !

The log shows if a commit was pushed when we checked out v4.93.xx or creatique_1132 so can retrieve more information that you say.

Maybe if the user selects (not check) a branch name in the Branches tab you could highlight the associated path in the commit tab.

Did you already try View|Branch Coloring?

Yes and it's nice when you want to highlight the current checkout branch. But if you want to highlight another branch you have to checkout it which is not good if you're working on the files at the same time.

Doing the same but without having to checkout the branches but just selecting them could be a way to do it.

Highlighted branch in black and the others in colors (or in all in color but with a very thick line for the highlighted).

You can do that by using View|Set Anchor Commit (only enabled for Merge and Branch coloring)

No this not what we're looking for.

I give up...

Many users report that the log window lacks a feature that would help to identify branches in the history of a GIT repo and you guys keep saying that this feature won't be useful and can not be done.

I do think it is possible to implement something to help users.

If you are able to highlight the current checkout branch you can do it using color when the user clicks on a branch name.

The last screenshot post by Thomas Singer is a good example of the user needs.

As far as I understand this is a flaw in Git design, not in the SmartGit interface.

With Git, a commit is not "on a branch", it is a node in a directed acyclic graph, with tags (branch names) at the top (see my previous comment).

If you want a version control system with named branches, you should use SVN (or maybe Mercurial, I don't know this one).

Very nice option !! Can a button be added just aside the view type drop down ? So when you select branch or merge coloring it would be available and really visible ?

"Maybe if the user selects (not check) a branch name in the Branches tab you could highlight the associated path in the commit tab."

 -- This in itself would be very useful IMO

"I give up... 

Many users report that the log window lacks a feature that would help to identify branches in the history of a GIT repo and you guys keep saying that this feature won't be useful and can not be done."

-- Clearly this is not a trivial problem, else I'm sure the SmartGit team would happily implement it. Everyone has suggestions, but each one has flaws.

Given that, perhaps a more productive approach would be to try and find an existing tool other than SmartGit that appears to handle this correctly / better for Git repositories. Has anyone found such a tool?

"This in itself would be very useful IMO"

1. Using the info returned by GIT you are able to draw a label with the name of the branch to visualize on what commit the branch points to, let's call this commit the BranchRefCommit.

2. Also with the info returned by GIT you are able to connect commits using colored lines, let's call these lines BranchPath.

3. Using internal variables (in SmartGIT) you could :

  a. Associate each BranchRefCommit to branches names (i.e. origin/v4.93.xx and v4.93.xx)

  b. Associate each BranchRefCommit to BranchPath

4. When the user clicks on a branch name, you can retrieve the BranchRefCommit which can be used to know the BranchPath and then highligth the associated lines. BranchPath could be a list of commits' SHAs or a list or lines coordinates and colors.

This works only for existing branches which is OK since GIT only stores useful data.

"Given that, perhaps a more productive approach would be to try and find an existing tool other than SmartGit that appears to handle this correctly / better for Git repositories. Has anyone found such a tool?"

What does this mean ? If nobody else made it you should not try to make SmartGIT better than other tool ?

What does this mean ? If nobody else made it you should not try to make SmartGIT better than other tool ?

What I meant was "if some other tool does this better/'correctly', we can examine its behavior and use that as a concrete example of what SmartGit should/could do".

I can agree with the devs that sometimes finding out what popup hint for each branch to show, is not always as straightforward as some of the examples make it seem:

But that's exactly why the request for this feature exists.
We're all smart people here, I'm sure we can come up with a nice list of suggestions for this problem right?

Personally I would be happy if the lines themselves did not jump around so much.  Compare the following example from SmartGit with another popular git client.  Notice the other client keeps the main branch (Develop, in this example) in the same location.  But with SmartGit the Develop branch visually jumps across when a branch is made off the Develop branch, the new branch is shown in the position that Develop was in.  This makes it difficult to easily establish which branch is which.

SmartGit view:

Other git client view:

What other GIT client is it ?

Sourcetree

Same with a very simple repo...

Here with Smart GIT the master branch (which is the develop branch) is not kept on the left...it jumps right...

With SourceTree the branch is kept on the left as a straight line, which is easier to read...

Graph layouting may have contradictory goals: SmartGit is layouting your log with a single line crossing while the other Git client requires 4 line crossings.

What's the name of your "main development" branch? When using Git-Flow, the "development" branch will have a higher priority and stick to the left (at the cost of possible additional line crossings).

The main development branch is Develop.  The repo is set up for git flow (but not all branches are created using git flow).

I can't see the benefit of a goal of "single line crossing" .  It hides the main branch, and confuses what is branched from what.  Maybe it is just me...

I do agree.

If the branch jump too many time it can be difficult to follow it.

If Git-Flow is properly configured, develop should stick to the left.

For your SmartGit screenshot: the green line from above belongs to develop? To which branch does the red line belong? Which exact SmartGit version are you testing with?

Please try to compose a small example repository illustrating the problem.

Git flow is definitely configured and being used currently without problem.  Smart Git does NOT keep Develop on the left.

In my screenshot for Smart Git: Develop is in orange (eg see commit tagged "v2.10" on 7th Feb).  The red line is for a feature which branched off Develop on 22nd Feb.  The green line was for a feature branch (branched off develop on 16th Mar) - but this is also confusing, because in Smart Git the Develop branch eventually ends up being a green line...

Smart Git version 17.0.4

Sounds strange. To better understand this, I have to see at least the entire history from now to the point display on the screenshot. You may send the screenshot to smartgit@syntevo.com.

Also, have a look at: https://smartgit.userecho.com/topics/193-pin-branches-to-the-left-in-the-log/#comment-1193

Here comes a first glimpse of the new coloring mode. We plan to release a preview build the next week.

Feel free to give it a try at SmartGit 18.1 preview.

What is your opion about the implementation in 18.1 preview, especially also the "color legend" in the Branches view?

We've got the feedback that the black/white HEAD line in the light/dark theme rather should match the green used as current-branch triangle color. We also got the feedback that we rather should use the line's color as background color for the node in the Branches view (and toggle the foreground color to match the more contrast).

So far my only feedback is: I like it very much!

I also use "Increase max connector length" + "Increase rectilinearity" + "Preserve parent order" to get a more linear (but very wide) graph.

where are those options located ?

Please have a look at: http://www.syntevo.com/doc/display/SG/System+Properties#SystemProperties-smartgit.log.graph.layoutActions