https://bugs.kde.org/show_bug.cgi?id=379219
--- Comment #16 from mrnuke <mr.nuke...@gmail.com> --- In that case, you'd have to determine if the process holding the lock is still active in order to avoid an infinite loop. Or timeout after a while, increasing complexity for a very niche use case. Another approach is to introduce producer-consumer relationships between commands, where 'git status' is a consumer, but that introduces a complex hierarchy between commands. I'm not involved in git development, but if I were maintaining git, I would not consider running 'git status' in parallel with other operations to be a valid reason to add this level complexity. -- You are receiving this mail because: You are watching all bug changes.
