
Git Concurrency in GitHub Desktop - samlambert
http://githubengineering.com/git-concurrency-in-github-desktop/
======
dilap
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](http://gitup.co)

[https://github.com/git-up/GitUp](https://github.com/git-up/GitUp)

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

~~~
lojack
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.

~~~
jconley
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.

