https://bugs.kde.org/show_bug.cgi?id=379219
--- Comment #26 from Daniel Santos <daniel.san...@pobox.com> --- (In reply to Sven Brauch from comment #23) I understand your position that git may want to look at this. Has there been a bug report filed with them yet? I also think that I understand git's design decision to implement rebases as individual atomic transactions. None the less, KDevelop 4 did not have this problem, so something changed in KDevelop 5 that is leading to this. I learned long ago that if I don't put my build directory in an "exclude" filter and I try to run make on my project that my machine comes to a stands still because KDevelop 4 demanded all available CPU to continually rescan the file system, update the tree, etc., especially when I ran nice -n20 make. Further, when we're in the middle of a rebase, we don't even want to update the status in KDevelop for each commit, that will unnecessarily hog CPU cycles, and cause rebase operations to be significantly slowed down for no good reason -- this is especially true when source parsing is triggered! A long time ago I wrote an algo for saved game preview functionality for a video game. Producing the preview took some I/O and a fair amount of CPU. When the user tried to arrow down through the list, there was a 400-1000-ish millisecond pause in between each movement of the cursor. Even moving the saved game preview into another thread (where it belonged anyway) was still clunky because of the CPU and I/O. So my algo kept track of the recent frequency of changes to the currently selected file and when that was high, it delayed the onset of the saved game preview generation so that the user could quickly scroll without having the UI bog down. Then when they stopped moving the cursor through the saved game list, there was a reasonable 250-ish millisecond delay before the preview generation started. Maybe KDevelop needs something similar, so that it has a base delay before updating due to (unfiltered) file system changes (something small like 100mS), and as the frequency of such changes increases over a short time is high, that delay is increased and if the delay has not expired when another change occurs, the counter is reset. But KDevelop should still probably check if there is a rebase in progress. As far as git is concerned, I wonder if compound operations like "rebase" and "am" should have some mechanism to indicate that such an operation is occurring so that other operations (like "status") can pass a flag that tells git block until such a compound operation has either completed or is suspended (in the case of a merge conflict, edit, squash, etc.). Like "git status --dont-break-the-goddam-rebase-operations" :) -- You are receiving this mail because: You are watching all bug changes.
