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.

[cubuspl42]

It drives me crazy... :(

[cubuspl42]

@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 😂

[cubuspl42]

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

[cubuspl42]

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.

[cubuspl42]

@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.

[cubuspl42]

@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.

[cubuspl42]

@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.

[cubuspl42]

Thank you very much for the investigation!

Just so there's no misunderstanding; I've been observing this regularly on multiple computers on multiple repositories, it's not specific to this repository.

[cubuspl42]

@lucasderraugh Did you create an issue in libgit2? I could also do it, but I have extremely limited libgit2 experience. Is there any limited simple set of libgit2 invocations that would let me produce the surprising timestamps?

[matthewhively]

I get this issue all the time. Usually happens when rebasing. Sometimes it will go away if I juggle the positioning of some commits (move up, then move down again), sometimes editing the commit messages will fix it.

[soleo]

I am wondering it might be fixed by updating libgit2, GitUp currently uses a fork https://github.com/git-up/libgit2, and it is behind comparing to current libgit2. Might worth to try update to current version to see how it looks

This branch is 73 commits ahead, 2965 commits behind libgit2:master

[cubuspl42]

@soleo That a great find! @swisspol Would it be possible to rebase the fork, or is it too far behind?

[swisspol]

This bug is unrelated to libgit2: it’s in the drawing algorithm.

[cubuspl42]

@swisspol I was referring to posts by @lucasderraugh above. So do you think that the possible timestamp-related bug in libgit2 is irrelevant, and the drawing algorithm should not depend on timestamps?

[cubuspl42]

I'll allow myself to friendly ping this issue one more time. If this bug hits me again I'll probably have to switch to another git client =(

[sesam]

If you don't mind touching the commits, you can easily "paint" the dotted line solid by making the timestamps not be backwards. I get this issue when I move commits up and down a branch and sometimes when rebasing, and I think I did get it to reliably paint solid instead of dotted by "touching" the timestamp of the commit on the tip of the current branch.

[cubuspl42]

@swisspol @soleo @lucasderraugh The bounty bumped to $200

I'm seeing this on every repo, every day. I really have no idea how this is not the most annoying bug in GitUp for everyone. Maybe it's about my workflow. I rebase a lot. No idea.

[cubuspl42]

The worse thing is that it's not just the line style. The buggy state makes the graph misbehave, things aren't clickable as you'd expect them to be... It's difficult to explain, but it's more than a purely stylistic thing.