Git Concurrency in GitHub Desktop | Hacker News Reader

Git Concurrency in GitHub Desktop

githubengineering.com

33 pointssamlambert5 comments

Open articleView on HN

For people just looking for a git client on Macs, I've been using GitUp for the past couple month's and it's amazing.

- In-app git implementation for all operations; does not use the git command line at all

- Lightning fast* (*for reasonably sized repos; it's not yet optimized for super large repos)

- Simple yet powerful UI -- treats git as a graph and let's you operate on that graph.

- Commit graph visualization that's actually useful (IMO)

I used to use mostly the command line with fallback to magit in emacs; now I almost exclusively use GitUp.

Obviously I'm still in the honeymoon/fanboy phase, but I really feel like it deserves to be better-known. Check it out!

http://gitup.co

https://github.com/git-up/GitUp

Perhaps I'm just feeling like a Grump Old Guy today itching for some down votes, but, why was concurrency control like this not in the client in the first place? Seems like a pretty core thing to an application designed to do destructive things to large swaths of files.

I bet the devs could code algorithms on a whiteboard like nobody's business though! /s

On a less-grumpy note, we really need a way in this industry to disseminate knowledge through the generations. I can't believe how many posts like this I read every day where someone rediscovers the same truths over and over again, that those of us with more experience also "discovered", and those before us, and so on.

It sounds to me like they erred on the side of caution on this and initially only performed Git operations serially. Presumably this allowed them to iterate quickly on a product without doing destructive things, with the downside being an unresponsive application. It likely wasn't built in to the product in the first place because it was seen as premature optimization. As the product matured it became more apparent that optimization was needed.

I'm also not so sure that this concurrency model was rediscovered. Sure, they applied it to Git, and created their own implementation, but they probably borrowed the idea from the countless Grumpy Old Guy's that have done this in the past.

Of course, this is all speculation. Feel free to correct me if I'm wrong.

I've been a user of this client for quite some time, and I've always had to use it with a light touch. Click one thing, wait until done, click another thing. Basically serializing things myself, because even though the UI allowed the input, the state of things would get really screwed up if you did things concurrently.

If concurrency control in a multi-threaded, multi-process, app is a premature optimization, well, wow.

At the end of the article the author states: "Before these changes, GitHub Desktop suffered from race conditions as units of work would become interleaved in error.

Since implementing the concurrent/exclusive locks we have seen an improvement in stability and performance. "

Sounds like they used to just let the client spin up multiple concurrent operations fairly willy-nilly.

The article gives me the impression too that originally it was assumed that some of the thread-safety guarantees of the underlying tools (libgit2, git) were enough.

Reply on news.ycombinator.com