File watcher wip #614
File watcher wip #614
Conversation
single watcher on the .git/ dir, and run the callback fn whenever any files are changed.
Also ensure repo state is loaded.
update functions now no longer need to be async - in fact, being async breaks things. So, these calls can now just be sync calls.
entire thing every time.
tracked are wrapped in operation() function, which sets value. The value is only cleared after the status buffer finishes redrawing. This is a little hacky, and everything works _fine_ without it, but it's for the test suite. Async stuff is tough to test.
not return until the current operation (reset) is done
CKolkey
force-pushed
the
file-watcher-wip
branch
from
5dca5b2 to
b4666a3
Compare
Just do the refresh, otherwise we could miss stuff like FETCH_HEAD being updated, but index not
wrapped. So.. Don't check the return. Also, nothing uses this.
|
Could this PR solve the problem of existing buffers not being refreshed after switching branches using neogit? |
Hm. Maybe? I actually already merged a version of this a few days ago, so you can tell me if it works how you expect or not :) |
|
I tried switching branches or cherry-picking, but I still need to execute What makes me most curious is that gitsigns will refresh the existing buffer signs after performing these operations, which may mean that gitsigns also has a relatively complete "file watcher"? I don't quite understand the difficulty of this matter. The "better file change detection" on the Neovim roadmap seems to have been around for many years. |
|
Could you make a screen recording and open an issue? I cherry pick/change branches all the time and the status buffer is always right. Also, will refresh the buffer too :) |
|
Of course. 2023-09-01.19-13-38.mp4 |
Ohh! You mean the buffer. Thats not going to be managed by neogit, but you can add an autocmd on "FocusGained", "BufEnter", "CursorHold" events that runs |
|
Thank you! That's very useful. Some git integrations like fugitive, could reload the buffer after these commands are executed. If you are not interested in such a feature, I might implement it when I have free time. |
|
You're welcome! If you want to, thats alright, but I'm hesitant to start messing with users open buffers. I kinda want to draw a line that starts at the status buffer, and say that everything from the status buffer onwards is ours, but everything before that is not. |
Major changes:
Watcher
.git/folder. Any changes will refresh the internal state for the repo. The major advantage of this is that during things like a cherry pick, merge, or rebase, etc, the status buffer will always be correct. The filesystem watcher is debounced to prevent over-eager refreshing.Repo
#dispatch_refreshto refresh the repo state in an async context.index_statadded to capture timestamp of.git/indexand not refresh repo state if the timestamp hasn't changed. Possibly dumb.Status
status.refresh()no longer takes a table for which things to refresh. We can just refresh everything every time as it's always done in an async context.M.update()calls to some of the status buffer actions to trigger a state refresh.M.get_status()doesn't seem to be used anywhere.. Though now I'm wondering if it's not part of our "public api" :\Other
a.util.scheduler()andstatus.refresh(). The action's function is wrapped, and the scheduler/status functions are always invoked. The biggest disadvantage of this is you don't see the name of the function that ran, but in practice that wasn't used.