Indicate First Parent in Graph

[dsChristophB]

Feature description

The graph view should clearly indicate which parent of a merge commit is first parent. The respective parent line should go vertically down from the merge commit.

Note that there is the solved #5819 which only refers to the left-most column. Generally, the order of the parents seems not to be indicated yet (Example from the Git Extensions repo, I marked f for first and s for second):

I would prefer to see the second example similar to this (sorry for the ugly painting):

Environment

• GitExtensions version: 3.1.1.6049
• GIT version: 2.21.0
• OS version: Windows NT 6.1.7601 Service Pack 1
• .NET version: 4.7.3416.0

[gerhardol]

Why is this important?
If added, it may distract users why this would require yet-another-configuration-option.

[dsChristophB]

Why this could be important:
In a larger project, less-experienced developers could contribute code accidentally containing merges in the wrong direction (i.e. not following the general branch strategy). If this is not noticed immediately, it cannot be fixed later. Wrong merge directions will interrupt the first-parent history and this may disturb the change log (for which the general branch strategy may be set up).
In this case, all reviewers should immediately see that "something is unusual".

[gerhardol]

You see the commits (sha) in the commit info panel and can derive this info from the graph.
If this is implemented I would suggest to draw the secondary (really not first) parents with thinner lines, placing of s, f will be confusing.
Still not fully convinced that a configuration option is worth it, but a subtle rendering of secondary parents could be OK.

[dsChristophB]

Sorry, I was not very clear: The proposal was to draw first parents with vertical lines, just like SourceTree does it. The s and f markers should only show that it is currently not possible to identify the first parent only from the graph.

[RussKie]

In the past 7-8 years working on various repositories in various teams I have never found myself (or anyone I have worked with) depending on how first-parent was rendered.
However I'm not commenting on the actual proposal, but on the reasoning provided. It doesn't make sense to me, sorry.

In a larger project, less-experienced developers could contribute code accidentally containing merges in the wrong direction (i.e. not following the general branch strategy).

• What do you mean "in the wrong direction"? If commits contian orthogonal (to each other) changes they can come in any order. Arguably they must not be part to the same PR.
  Further less-experience developers should be mentored by more-experienced developers, and that's why pull-requests should be reviewed.
  Any changes should ideally be going via a CI pipeline that catches compile-time (if appropriate) or linting errors before a merge is allowed. Again, GE has nothing to do with that part.
• "following the general branch strategy" - each team decides on preferred branching strategies, there is no universal branching strategy everyone has to follow. So it doesn't make sense to institute this in a general purpose tool.

Wrong merge directions will interrupt the first-parent history and this may disturb the change log (for which the general branch strategy may be set up).

Again, this makes no sense... Any merge has 2 parents, there is no "right" or "wrong" direction here.

this may disturb the change log (for which the general branch strategy may be set up).

It depends how you generate you log. If you're having troubles generating a correct change log between two given points in history, perhaps you're not doing it correctly.

If this is not noticed immediately, it cannot be fixed later.

This sounds misguided. Everything can be fixed later (e.g. reverted or force-pushed, if really necessary). It may be painful however.
If you're finding yourself in this situation perhaps you may need to review your development practices.

[dsChristophB]

Thank you for the elaborate explanation. Apparently, my English is not good enogh to make my point clear. My simplification concerning first-parent history was pointless. I try again using a real example:

There is a project with two parallel branches and occasional merges between them and a branch strategy which allows only one global merge direction, in this example view only red to blue.

The red commits appear in a second parent history of the blue branch. I used SourceTree for these screenshots, which draws the first parent lines always vertically at the merge commits.

If there are merge conflicts, these have to be resolved by another (non pull-request) merge (6th line):

Note that the lower two visible red commits are still in the second parent history of the blue branch.

The person to submit the red-to-blue merge may -accidentally or not- do it like this:

The file contents are the same, but the non-PR merge commit has its parents swapped. Now the second parent history of the merge (PR 35000) goes again to the blue commits. The red commits are one level deeper. This may be slightly confusing in future analyses. I would like to understand situations like these at first glance even when not thinking about history depth. Unlike SourceTree, Git Extensions does not show a difference between these two patterns:

This is aesthetically quite pleasing but I would prefer to see the ugliness if it is there.