Visual glitch in graph, thin dashed line all the way

[mcdado]

I know this feels a bit anal retentive, please bear with me…

It seems that if the last changed branch is not a tip, the whole line graph for that branch is thin and dashed.

In the case of this screenshot, I rebased pixart on top of master, which created a bold branch to the top left (before it was to the right, being a branch spun out of master earlier on, the remote-tracking branch is still there).

I also had a branch called import-new-features which was before the tip of pixart (also seen on the right with the remote-tracking branch). To update it's location, I used the "Set Tip" on the corresponding commit of the newly rebased branch. This cause the branch import-new-features to be the left-most, and since it's not a bold-line change, it has a thin dash line. The problem is that it doesn't stop at the juncture with pixart, it goes all the way down to the beginning of time, and you can see white breaks due to the commits dots. I would need to make some commits on either branch to solve the visual glitch.

Another way to go about it would be rebasing import-new-features instead of pixart, set pixart's tip to import-new-features and then cherry-pick the commits from the remote-tracking branch. With a couple of commits it's fine, with a more a complex history it becomes a bit tedious.

[swisspol]

That's a known rendering bug in the Map.

[jakub-trzebiatowski]

It drives me crazy... :(

[jakub-trzebiatowski]

@swisspol I'm literally willing to pay to get this one fixed. It's the only bug I ever encountered in GitUp, but it happens regularly and ruins my productivity

[lucasderraugh]

If you put up a bounty, somebody might take you up on it 😂

[jakub-trzebiatowski]

@swisspol @zwaldowski @soleo @lucasderraugh
https://www.bountysource.com/issues/46687073-visual-glitch-in-graph-thin-dashed-line-all-the-way

[jakub-trzebiatowski]

I raised the bounty to 65$

Is there any way I can help with solving this issue? For example is there a need for providing a snapshot of a git repo which causes this glitch to occur? Or anything else? I know that I could "just send a PR", but I'm not familiar with the codebase at all and don't feel strong with Objective-C. But if you pointed me to the part of the codebase where the root cause of this glitch is located, I could also take a look.

[lucasderraugh]

@cubuspl42 If you have easy and precise repo steps I can take a look. I’m not sure how to repro at the moment.

[jakub-trzebiatowski]

@lucasderraugh

Repo

Clone the repo:
git clone https://github.com/cubuspl42/WapUniverse-gitup-bug1.git

Checkout the other branch (there are two remote branches in the repo):
git checkout set

Alternatively, you can press Shift + Cmd + R (Remote Branch Tips), it also reproduces the bug.

Sometimes a small commit change can pull the app out of the buggy state, sometimes it takes a dozen of Git tree modifications. But once a buggy tree state is reached, the bug is deterministic and you should be able to reproduce it by checking out all the branches in the example repo.

It's really difficult to tell what causes the buggy state to appear in the first place. Typically it's some kind of rebase or amend.

This happened to me like twenty times at my workplace in the last two weeks, but I can't share my workplace git repo for obvious reasons. I even tried to anonymize the work repo by running filter-branch on it, but it took the repo out of the buggy state. So it's not the shape of the tree itself, SHA/content also matter.

Today it "finally" happened in my pet project, so I'm sharing the affected repo with you as-is.

[jakub-trzebiatowski]

@lucasderraugh
I'm respectfully bumping a thread and reminding about the bounty. This is still happening to me nearly every day.

[lucasderraugh]

Thanks @cubuspl42, I was able to reproduce it with your repo. I'll take a brief look today.

[jakub-trzebiatowski]

@lucasderraugh Awesome, thank you! I've already seen this four times today at work, I'm glad it might finally go away! <3

[lucasderraugh]

So I believe I found where an issue lies with your particular case. There is logic for sorting the latest commit to appear first for an array of tips. For some reason the date that we're reading in doesn't have the right timestamp. Comparing git log output from @cubuspl42's sample repo, I get the following:

Date:   Tue Dec 3 09:56:40 2019 +0100
  Set WIP
Date:   Tue Dec 3 09:56:29 2019 +0100
  WIP fix test (?)

So we can see they are a few seconds apart. However the sorting in our app receives the times as

(lldb) po tipsArray
<__NSArrayM 0x6040005fab10>(
[GCHistoryCommit] 5fe1c13 '2019-12-03 19:41:12 +0000' Jakub 'WIP fix test (?)',
[GCHistoryCommit] 17bb936 '2019-12-03 19:41:12 +0000' Jakub 'Set WIP'
)

For some reason the timestamp seems to be completely wrong and the problem lies in the fact that they are identical and so the sort ends up putting the virtual tip first where it would have been second.

[lucasderraugh]

So libgit2 is parsing these out as such (the second being the time it takes which is at the end):

(lldb) po time_start
"1575363389 +0100\ncommitter Jakub Trzebiatowski <cubuspl42@gmail.com> 1575402072 +0100\n\nWIP fix test (?)\n"

(lldb) po time_start
"1575402072 +0100\n\nWIP fix test (?)\n"

(lldb) po time_start
"1575363400 +0100\ncommitter Jakub Trzebiatowski <cubuspl42@gmail.com> 1575402072 +0100\n\nSet WIP\n"

(lldb) po time_start
"1575402072 +0100\n\nSet WIP\n"

I'm not sure what the difference between the 2 times are, but it would explain the reason the sorting fails. I can ask the libgit2 folks perhaps.