Hacker News Reader

Comment by jconley | Hacker News Reader

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.

View on HN

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