Git Repository Network Graph commits out of order

Hi I use GitLab for 2 years already. One motnth ago I discovered weird situation on Graph of my project. (I use tortoise git on Windows) Example: There are 2 branches "develop" and his child "front" I made commit of my develop branch on local, then made pull from front to develop on local, after that i used "sync" to push changes to remote develop branch.

After that I see something like that

Lines going out of the graph field When I try to merge branch front to develop on GitLab page there is no commits to merge. When my friend make pull from remote/front to local/front then graph starts looking fine.

Why this happening ? I was using the same procedure many many times and everything Was allright. During last month every time I try but I have the same situation.

Can anyone help me to solve this ? Is this a bug or maybe I am doing something wrong?

Same issue to me. GitLab's graph system has been strange since yesterday. Commit Logs aren't in sort by date and some part of graph is erased.

Same here.

I've also been seeing commits out-of-order

Same for me, it makes it very difficult to see what is happening with the repository. :-(

Is everyone here seeing this issue on GitLab.com or your own GitLab instances? Please could you add the GitLab version of your instance if this is the case? Thanks!

Mine is hosted on GitLab.com

@markglenfletcher I use gitlab.com, version: GitLab Enterprise Edition 9.1.0-rc3-ee e3cefc2 Here I cant see the end place of graph, cant work using gitlab now. Is there any way to help you find this problem? I am glad to help and waiting for response.

I'm using gitlab.com too.

yes, I'm also gitlab.com too.

Same with me and my entire group. We are using gitlab.com too. As far as I remember, this issue started from GitLab 9.1 RC1 release.

added frontend ~12980 graphs repository labels

@jschatz1 Please could you take a look?

Same issue here on gitlab.com.

Hi, I'm having the same issue. My entire group works on gitlab.com. We are facing this problem since 13 April.

@amandachagas That graph is so awesome.

Same here.

Same for me, only deleting of merged branches helps me...

For languages branch, which is behind master in one commit:

For master branch:

How it should be:

It looks to be a regression issue. It would be good for a ~Frontend team member to confirm.

/cc @iamphill

Thanks for the updates everyone

The only thing I can see that has changed is 34742710. Not sure if that has caused this issue. @markglenfletcher

I noticed in our graph that the dates are in the correct order BEFORE March 4. Is that consistent with the rest of you?

mentioned in issue #31286 (moved)

mentioned in issue gitlab-com/support-forum#1756 (closed)

Same problem here!

@DouweM Are you aware of any backend changes for 9.1 that could be having an impact on the Network graphs please?

Have the same issue after upgrade to 9.1. Did not do any changes on backend or server just upgraded from repo and now graphs displaying incorrectly. Server: ubuntu 16.04

@iamphill this thing is a library right? What's the deal with this chart?

@jschatz1 I honestly don't know, I couldn't see any changes that would cause it to look weird. I can look into it more to see what is actually happening!

@iamphill I mean, this viewer. It's an external library right? It looks way different than the rest of GitLab and has been in since before I joined.

@jschatz1 Raphael. Files are here https://gitlab.com/gitlab-org/gitlab-ce/tree/master/app/assets/javascripts/network. We just get data from backend & then build the graph ourselves.

added regression label

mentioned in issue #31430 (closed)

From a 10,000-foot view, this smells like a sorting issue. It looks like https://gitlab.com/gitlab-org/gitlab-ce/network/master may be affected too? We upgraded to Rugged 0.25.1, which may have caused commits to show up in a different order: https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/10286/diffs#149543c1229cd4353b9ad020503ffb49dedf5f1f_386_385

added Next Patch Release label

changed milestone to %9.1

changed title from problem with actual position in Graph to Git Repository Network Graph commits out of order

mentioned in issue #30864 (closed)

I think it's just a matter of tweaking the Rugged options in https://gitlab.com/gitlab-org/gitlab-ce/blob/v9.1.0/app/models/network/graph.rb#L108-111: http://www.rubydoc.info/github/libgit2/rugged/Rugged

@adamniedzielski Looks like a regression caused by the update to Rugged.

added ~480950 and removed frontend labels

assigned to @timothyandrew

mentioned in merge request !10936 (merged)

closed via merge request !10936 (merged)

mentioned in commit 4d4aefc5

mentioned in commit c6b13536

Sorry guys but I still see the same wrong graph as yesterday.

If necessary I can send some comparison between the GitLab graph and the gitk plot...

Pls fix it, it's very annoying...

Bests

Rudy

@rudy.becarelli Are you running your own instance, and patched it by yourself? Or are you using GitLab.com? If you're using GitLab.com, we haven't deployed a new version yet. This is scheduled to be released with 9.1.2, which is scheduled on Monday.

@godfat I'm on GitLab.com

Glad to hear that the issue will be fixed in the next release on Monday!!!

Thnx for your effort guys!

Have a nice day.

R.

Apparently this issue is not resolved yet. Some commits are still out of order like these:

Here is my gitlab-rake gitlab:env:info output:

System information
System:		Ubuntu 16.04
Current User:	git
Using RVM:	no
Ruby Version:	2.3.3p222
Gem Version:	2.6.6
Bundler Version:1.13.7
Rake Version:	10.5.0
Redis Version:	3.2.5
Git Version:	2.11.1
Sidekiq Version:4.2.7

GitLab information
Version:	9.1.2
Revision:	df1403f
Directory:	/opt/gitlab/embedded/service/gitlab-rails
DB Adapter:	postgresql
URL:		http://192.168.0.33
HTTP Clone URL:	http://192.168.0.33/some-group/some-project.git
SSH Clone URL:	git@192.168.0.33:some-group/some-project.git
Using LDAP:	no
Using Omniauth:	no

GitLab Shell
Version:	5.0.2
Repository storage paths:
- default: 	/var/opt/gitlab/git-data/repositories
Hooks:		/opt/gitlab/embedded/service/gitlab-shell/hooks
Git:		/opt/gitlab/embedded/bin/git

I seem to be having this problem still too, on the 9.1.2 Omnibus release. I'm not completely sure what's going on here.

@timothyandrew Could you please investigate again?

reopened

I was able to reproduce this issue in my development environment. On a freshly seeded gitlab-development-kit installation, visit https://<gitlab_url>/twitter/flight/network/master?utf8=%E2%9C%93&extended_sha1=8a7b74b10ec5ed598b15e4d58bef24a33c75e694&filter_ref=1 to see this bug. This behavior is not present in v9.0.0.

---

I'm guessing this is a different issue than the previous fix (passing the wrong sort order to rugged). I'll investigate immediately.

It appears to be solved on gitlab.com. Since yesterday (05/02/2017). Thanks for the solution.

added customer label

ZD: https://gitlab.zendesk.com/agent/tickets/75199

I think I might have this figured out. There's one edge case here that !10936 (merged) doesn't fix.

Steps to Reproduce

• Create a branch off master called dev
• Make a number of commits in dev, with at least one second in between them (each "Commit Time" should be different)
• Cherry pick all these commits into master with a single command (git cherry-pick master...dev)
• All (or most) of the commits in master should all have the same "Commit Date" (but different "Author Date"s), since git doesn't record timestamps more accurate than one second.
• Push this branch up to GitLab and view the network graph. I get something like this (commit names generated randomly from /usr/share/dict) for what should be a simple flat graph:

Solution

• We need to order by commit time, but also disallow parents from appearing before children to avoid this edge case.

• We can do this by combining SORT_TOPO and SORT_DATE for the rugged sorting strategy (the current strategy is simply SORT_DATE). From the rugged docstring for SORT_TOPO:

  this sorting mode can be combined with time sorting to produce git's "time-order"

• Changing our sorting strategy to Rugged::SORT_DATE | Rugged::SORT_TOPO, we get a graph like this:

---

I'll create an MR for this asap.

/cc @adamniedzielski @godfat

mentioned in commit ed1e60ad

mentioned in merge request !11057 (merged)

mentioned in commit 258cc85a

ZD: https://gitlab.zendesk.com/agent/tickets/75214

mentioned in commit b44eaf8e

closed via merge request !11057 (merged)

mentioned in commit 37b1b14a

reopened

Hi guys. There are still some problems with graph.It looks different than befere but still not right @timothyandrew , @godfat

Example:

I merged develop to master:

But on the graph i see something like that:

Second problem is cut line in the history

Do you have any idea how to solve those ?

Thanks for the report, @smokarz. I'll take a look.

Edit: What version of GitLab are you running?
Edit 2: I see from your first screenshot that you're running GitLab.com. The most recent fix (!11057 (merged)) has been merged into master, but has not made it into a tagged release yet. I'll close this issue back up for now - please feel free to reopen if the issue persists when GitLab.com is updated to either 9.1.4 or 9.2 - which should contain the fix.

closed

mentioned in issue #31939 (moved)

mentioned in issue #32026 (closed)

mentioned in commit f7b06bb6

mentioned in issue #32097 (closed)

mentioned in issue gitlab#9696