Kinked branch lines with similar colours cannot be followed by eye

[mikebeaton]

Hi - yet another one, sorry! I hope this input is helpful and useful - I'm only creating (several of!) these because Fork is a GREAT product! (And currently free - btw, seriously, I would have happily donated something already, if you had a donate link - I looked for one! :) )

I noticed that you have these kind of kinked branch lines (visible in the screenshot on your own homepage),

What has happened on my repository is that a kinked branch line has got pushed right next to another branch line and then two next door branches have also randomly ended up with very similar colours, which makes the branch structure almost impossible to read:

In the above, it looks exactly as if commit 10281b9 has 30235f3 as a parent, but it doesn't; there's a kink in the line, and it then passes down to 1a8ec76 and then to the shared root of fc99e60 (as it should for a merge).

To actually be sure what was going on, I had to open gitk, which showed it like this:

As I say, the fact that two next door branches randomly got very similar colours makes the branch lines very hard to follow by eye - perhaps some code to prevent that happening would be possible to add? I think that maybe arguably the use of the 'kinks' in the branch lines maybe doesn't help either? (But I can certainly see that there won't be any simple of perfect solution to something like this!) [EDIT: And/or, I wonder if there might possibly be a way to prevent kinks getting pushed too close to the near-horizontal parts of other branches, which perhaps would also have kept these two apart?)

I want to say, once again, many thanks for a lovely product!

[DanPristupov]

Hi

It it seems you are using topo-order in Fork and date-order in gtk. Could you try to switch that in Fork preferences and show the screenshot again?

[mikebeaton]

Hi Dan,

Actually it's in date order in Fork. I could try to revert (a local copy of) the repository back to this state and send an image in both sort orders, if it would help?

Mike

[mikebeaton]

(But surely one could generate some potential commit tree with exactly the branch structure I've got, for either sort order?)

[DanPristupov]

Drawing graph is hard, however I'll be happy to improve it. I can dig into this one day, but I need to see same info, at least.

On your screenshots in Fork HttpsTrue is above cors and in gitk it's opposite. I can't give any precise answer seeing them.

I suppose this issue can be related to that one in the Mac tracker: https://github.com/ForkIssues/Tracker/issues/345

Update: it seems to be exactly the same issue.

[mikebeaton]

Okay - I see - no problem, of course! I'll get the same image in the same ordering on both. (I think I need to revert the repo to that state and then switch gitk to date ordering, but whatever it is, I'll look into it!)

[mikebeaton]

Hi, I've reset my repo to something similar (at least, showing the same issue), and forced gitk to display the commits in the same (date) order as Fork. (I've also added a screenshot of Bitbucket's version, again in the same order.)

Here is the Fork display. For me, it is very hard to follow the path from 0223a0e down to fc99e60 (it looks very much as if it joins back in at 30235f5, when it does not).

I think that this is for two reasons (i.e. that changing either would help): 1. Because the 'kink' has been allowed to occur nestled in right where the rest of the tree gets crowded, and 2. Because adjacent branches have been allocated very similar colours. (I do appreciate this stuff is very fiddly; that neither of these proposed 'fixes' might be at all trivial; that they might have other side effects I haven't thought of! And I appreciate your work in making this!!)

Here is the same tree in the same order on gitk:

And here in Bitbucket:

Hope these are more helpful in being directly like-for-like.

Thank you!

[DanPristupov]

OK, I made some improvements.

Fork 1.29

Fork 1.30 (should be released by the end of the week)

[mikebeaton]

Many thanks indeed for all your the work on this.

The less sharp kinks do indeed make the branches easier to follow, so thanks!

If I can say, to me, looking at the improved page you've shown just above, the commit "Add iframe attributes to React" still does have hard-to-follow lines (which blue line goes in to join the node on orange, and which one carries on down?). If horizontally adjacent branches we forced to always have significantly different colours, I still think that might well additionally help.

Many thanks again. I still like Fork very much! Thank you.

[jerone]

@MikeBeaton commented on Mar 20, 2019, 11:00 PM GMT+1:

If I can say, to me, looking at the improved page you've shown just above, the commit "Add iframe attributes to React" still does have hard-to-follow lines (which blue line goes in to join the node on orange, and which one carries on down?). If horizontally adjacent branches we forced to always have significantly different colours, I still think that might well additionally help.

Agree. Maybe the color pallet could be extended with more colors.

Many thanks again. I still like Fork very much! Thank you.

Also agree :)

[DanPristupov]

I just published the 1.30 update!

[sm-g]

please do not limit number of colors!

this also may be related https://github.com/ForkIssues/TrackerWin/issues/308#issuecomment-500355335