There are some controller timings that are red https://drive.google.com/a/gitlab.com/file/d/0BzQDcBnEfNRZZV...
And the git access timings are a sea of red https://drive.google.com/a/gitlab.com/file/d/0BzQDcBnEfNRZTz...
Git access will be improved now that we have Gitaly as part of this release. In GitLab 9.1 we want to move git access from the application server to the file server. That should greatly reduce the latency.
In any case, it's just a matter of relative performance and perception in relation to what one runs on, and their needs.
VSCode is certainly nice and fast, but I've been able to do choke vscode a lot faster than Sublime.
Plus, you can't even open files above what, 100(?)mb in vscode whereas Sublime happily opens that in a snap.
I understood the OP's question as what is similar to Atom, but faster, is it VS Code?
My query being you can effectively use the native pre-receive hooks & wrap the git shell to allow consensus without needing to replace git with an RPC system like Gitaly.
We looked into Git Ketch https://www.infoq.com/news/2016/02/google-kick-starts-git-ke... for a distributed system based on hooks. But this requires a sync per repository (very slow with 100k+ repos per server) and it is no longer actively being worked on by Google.
There are plenty of off-the-shelf consensus algorithms/services you could use in the git-hooks that don't have the git-ketch limitation. Zookeeper, etcd, consule, redis, etc. It really just matters your criteria and requirements, they all of trade-offs but I'm sure one fits.
To be frank I think your time is better spent looking into why one of these consensus packages isn't the right call for your needs. Since they could easily plug into the git-hooks & git-shell commands, it could avoid a massive investment of time from your team and you.
A little while ago I spent a night and I was able to get a fully distributed git http server up and running. I used HBase and was able to get it most things working. That allows the only contention to be around refs. Everything else is well distributed and spread across as many machines as you need. Caching is handled on the key value store side, and the http server side. I didn't get to git gc work though.
This is solved without modifying the git client using a distributed/shared lock wrapping the git-shell & git-hooks (pre-receive) . If you were to modify the git server behavior to say use epaxos, one could provide even better latency guaranties https://www.cs.cmu.edu/~dga/papers/epaxos-sosp2013.pdf .
I'm not sure about the GC operation though, did you use the DfsGarbageCollector that is part of Jgit? I thought that was provided as part of the DFS interface.
http://download.eclipse.org/jgit/docs/jgit-2.0.0.20120613090...
The way GitLab is organized (pre-Gitaly) makes it very hard to do things like that. Roughly speaking, when handling a push, it is a coordinated dance between GitLab components to make sure it all goes in, but none of these components has full control over the push from start to finish. One of the reasons we are creating Gitaly is to create a 'place' (namely Gitaly) where we _can_ exercise such control.
The other big reason for building it is not having to use Git repos on NFS.
(Gitaly maintainer)
The problem is that we can't measure Unicorn timings with Prometheus since it is multi-process. Our Prometheus team is working to fix this for everyone.
There's lots of discussion there. We went with a design that leans on getting out of your way and recovers some screen real-estate. We do recognize the one additional click required though. And we are actively listening to feedback and will continue to iterate.
We're working hard to improve usability and navigation in general. In addition to this sidebar change, we've made many nav updates: https://gitlab.com/gitlab-org/gitlab-ce/issues/26348.
I find that this is more intuative to use than a hard on/off only.
Ideally this should be an option. I get that 'modern UX' is all about more screen space and whatnot, but I'm not a fan of that trend personally. It seems that all that's been gained from that change is more empty space at the side of pages. Personally, I'm the type that would rather have more information and convenience on the page than extra space.
Would it be that hard to add an option to enable the side bar if people want it? That's what I like about GitLab, that it's very configurable.
We are definitely focused on usability, and navigation in general. We don't claim to know all the right answers all the time. So we are iterating with each release, and working hard doing user research as well to inform our decisions. You can see some of our recent work regarding nav here: https://gitlab.com/gitlab-org/ux-research/issues/3. Thanks.
9 months ago we went through a very similar version of this: https://gitlab.com/gitlab-org/gitlab-ce/issues/18542
Can we just all agree to keep the damn sidebar available - if UX wants to remove it, fine, as long as users have the ability to easily permanently pin it back open if they wish to do so.
By now GitLab UX should realize that enough developers find great utility in that sidebar.
However, I do stand behind the main points of what I wrote:
1. It's disappointing and frustrating to see what is almost the same issue coming up only 9 months later (please look at the link I shared above), where now I'm seeing all the same arguments in favor and against the side bar in these comments as well as in the new related issue thread. We are going through almost the same exercise again.
2. On removing the sidebar - allowing the sidebar to appear and be pinned would be a more inclusive UI/UX choice. Please allow us to pin it again.
I will also add that over the last 1.5 years we've been using GitLab EE the GitLab team has been awesome. I'm continually amazed at how quickly many feature requests become part of GitLab.
Also, just being nice is a generally good principle.
It felt like without the side bar there is wasted screen realestate that could have project related options or navigation in the side bar.
As resolutions and screens get larger I'm a strong believer that as long as you don't over complicate or make the interface too busy, you shouldn't waste ⅔ of a web site with white space.
Regardless, very happy with 9.0 otherwise, another fantastic release from the team and contributors.
But one change that I did not like was the the removal of the side panel which could be pinned. Navigation required fewer steps, but now an extra click is required to bring up the options.