git/commit view and multiple copies of the files with changes in the normal view

[René J.V. Bertin]

On Friday December 18 2015 18:17:43 René J.V. Bertin wrote:

Actually, I can reproduce the weird behaviour described below in 4.90.90 KF5 version from around April, on Linux.

- open a git/commit patch review view containing one or more files with changes
- use the widget in the top-right corner to switch back to the code view: multiple copies of that (those) file(s) are open. You may even see them being opened if your system is slow or swamped enough, before the patch review view is fully opened
- switching back to the patch review view and cancelling the commit will leave multiple copies open (happened at least once to me).

It seems that the underlying issue here is that somewhere during the patch review generation, files are being opened multiple times, and left open in the (hidden) normal coding view. Can anyone confirm this, either in 4.7.2 or in the current 5 version?

Thanks,
René

>Here's a bit of weird behaviour I've just begun noticing in one of my sessions (KDevelop 4.7.2).
>
>Normally, I can use git/commit (from the context menu) to open only the files that have non-committed changes; when I cancel the commit, those files remain open.
>That still happens when I have at least one file open (regardless whether it has uncommitted changes). But when I try to use this feature to open only files with changes from a clean slate, I end up with 2-4 (and sometimes more) copies of each file open for editing.
>Curiously I've never noticed before; could this be related to a dbus/klauncher/kio/whatever IPC glitch currently happening on my system?
>Can anyone reproduce this symptom?
>
>Git/Show DIfferences has the opposite effect: it closes all files with changes, which may part of a patch I introduced (initially intended to prevent frequent crashes on closing the patchreview view).
>
>PS: I'm still getting close to updating to KDevelop5; there are too many small and less small things with KF5 Frameworks that I want to address first, and I prefer to do that using tools that are not affected by them (i.e. KDevelop 4.7).
>
>Cheers,
>René