koog1000 / vscode-fossil

Integrated Fossil source control for Visual Studio Code
Other
68 stars 8 forks source link

‘Open Changes’ shows wrong diff #129

Closed vor0nwe closed 10 months ago

vor0nwe commented 1 year ago

When clicking on a changed file in the ‘Source Control’ pane, a new editor opens, titled "filename.ext (Working Directory)", showing the file from the repository, side by side with the current file, and highlighting the differences.

When I commit the changes, the file disappears from the list of changed files in the ‘Source Control’ pane. When I subsequently make new changes in that same file, it reappears in that same place. So far so good. But now when I click on it, it does open an editor showing side-by-side, however it shows both the new and the previous changes (which have now been committed, and therefore should not be visible).

It would appear that the plugin remembers the revision that was active when I first opened the workspace, and always bases its diffs on that, instead of comparing the local file in the Work Directory with the unchanged version from the repository (which is what fossil diff does — correctly).

senyai commented 1 year ago

Thank you for your report. Afaict the plugin reports 'current' as the name of the check-in and the caching is happening on the vscode side. I will see if I can change 'current' to the checkout hash reported by fossil status. I will take a closer look in a week.

senyai commented 1 year ago

@vor0nwe even though you described your steps pretty clearly, I'm not be able to reproduce the issue. Can you record a video or describe it step by step with more details?

senyai commented 1 year ago

@vor0nwe I was looking into this issue and still not sure how it can happen. Do you remember by chance, did you make a change when vscode was focused?

vor0nwe commented 1 year ago

@senyai I’m sorry I haven’t been able to respond earlier (nor can I go in depth now), but the problem still occurs, with multiple repos, and on nearly all my machines. If you can’t reproduce it, then I suspect it might be caused by one of the many other extensions I have installed. The repos I most work with are from work, and I’m not supposed to record their code, so I can’t share a video.

I will try to see if I can reproduce it with only the fossil extension activated whenever I work on that code base, which should be in the course of the next few weeks.

senyai commented 1 year ago

@vor0nwe if there's anything I can do to help us find the cause of this issue, please let me know. I was thinking maybe a zoom/meet/any session or something.

pekeler commented 1 year ago

FYI: I have witnessed this problem as well, many times. Always having to close the file to reset the diff cache is annoying. I'll try to record a video soon.

pekeler commented 1 year ago

Here's a recording. I've made some changes to a couple of files, viewed the diff (worked fine), committed, left all the tabs open, made a couple of new changes, and now the diff is broken because it shows my previous changes plus the latest changes together as if the previous commit didn't happen. Closing and reopening the diff tab doesn't help. I have to close the tab for the file itself to get the diff to work correctly.

https://github.com/koog1000/vscode-fossil/assets/42363/c3fc9c88-79cf-492a-94df-67c70e857ffe

vor0nwe commented 1 year ago

Thank you for that, @pekeler! That’s exactly the same problem I have. Sorry I haven’t been able to get back to you @senyai; life, uh, keeps getting in the way.

Here’s a list of extensions I’ve got installed, maybe one of those causes the problem? (They’re not all enabled, but I can’t seem to find an easy way to export or copy just the enabled extensions):

senyai commented 1 year ago

I'm still confused about how it can happen. I can see that other scm extensions (git, hg) moved from TextDocumentContentProvider to FileSystemProvider to provide file content, maybe it is related. @pekeler thanks for the clip, I believe I need the full story there with commits and everything, as I can't reproduce it.

My plan is to release 0.4.0 today and release 0.4.1 with FileSystemProvider in a week.

senyai commented 1 year ago

Can you guys try 0.5.1 preview version (vscode only)? I moved from TextDocumentContentProvider to FileSystemProvider, but something tells me that's not gonna fix this issue. And if this preview version doesn't fix it, I need more info on what to do to reproduce this issue locally.

vor0nwe commented 10 months ago

I finally got round to testing it; and I’m glad to report that the issue appears to be fixed, at least in version 0.5.4! Thanks a lot, @senyai!

@pekeler does it now work for you too?