Feature to auto refresh tig status if any file changes

[jaseemabid]

Can't this be done with inotify?

[jonas]

Yes, it could. For now the auto refresh is quite stupid but at least it is supported regarless of whether the system supports inotify or not.

[jaseemabid]

I can't promise anything, but I'll try to do this.

I work with emacs + magit all the time, but magit over tramp on a large
repository is not as fast as it should be. Tig on the remote machine is a
good option in that case.

Thanks for the tool.
On Jun 18, 2014 7:18 AM, "Jonas Fonseca" [email protected] wrote:

Yes, it could. For now the auto refresh is quite stupid but at least it is
supported regarless of whether the system supports inotify or not.

—
Reply to this email directly or view it on GitHub
#301 (comment).

[vivien]

@jaseemabid inotify is not recursive. I'd strongly discourage such an implementation if you don't want to enter a watcher and portability nightmare. I think the 'auto' or 'periodic' refresh-mode is quiet enough to handle refreshing the status view with a good compromise.

[jaseemabid]

@vivien The manual[1] don't talk much about this. Is there anything I can read to learn more?

1. http://jonas.nitro.dk/tig/manual.html

[vivien]

@jaseemabid the other main source of documentation is the tigrc manpage: http://jonas.nitro.dk/tig/tigrc.5.html, look for 'refresh-mode'.

[jonas]

One way we could avoid introducing new platform code would be to have tig launch a script and read events from a stream. Each platform could then have separate shell script outputting the events. There's also https://github.com/alandipert/fswatch which supports most modern UNIX systems. The code is GPLv3+ so it could be integrated but would have to be converted form C++ to C. I don't think it would require that much platform specific code to go with the latter approach. However, it might be tricky to get the event reading right if some of the platform APIs rely on signals. FD-based APIs should be find, since we can simply add a check for new events to get_input.

The current implementation is in:

• https://github.com/jonas/tig/blob/master/src/watch.c
• https://github.com/jonas/tig/blob/master/include/tig/watch.h

Note that it currently relies on both file checking, for example .git/index and .git/HEAD, as well as internal events from reading data via git commands, for example git status and git ls-remote . (for reading branch and remote information). The idea is that views which supports refreshing register themselves providing a bitmask of the events they want to listen for. The watch module then tracks changes to files and internal events and tries to propagate them to the views.

The strategy for maintaining the state is really broken at the moment, so maybe we should come up with a better one for this first before piling more stuff on top of it. One issue is that the bitmasks don't work for tracking changes to events in the index. For example, if I open the stash view from the 'Unstaged' changes entry in the main view, it will register itself for WATCH_INDEX_STAGED events. Since tig doesn't keep track of what unstaged files the stash view is showing, the view won't always get update even if tig sees that a file changed, for example if the user opened the status view.

Not sure if the above is somewhat clear. Anyway, the point is that to have reliable refreshing we need to change the watch module to track more information.

[rolandwalker]

A portable external tool is entr.

A first approximation of entr monitoring a repo is

git ls-files "$(git rev-parse --show-toplevel)" | entr -pd printf '%s\n' /_

with the only wrinkle being that entr has two modes of action: upon modification to the listed files, it executes the given command (printf); upon other modifications to the directories containing the listed files, it exits.

An interesting thought is

while true; do git ls-files "$(git rev-parse --show-toplevel)" | entr -pd kill -USR1 "$TIG_PID"; kill -USR1 "$TIG_PID"; done

[msudgh]

Did this feature implement? what's the current status? I'd like to have a PR about this feature.

[rolandwalker]

Some time ago I sketched out an implementation indea in #734. It seems like the momentum got lost there. There is an unexplained test failure.

However, I have been using that branch in my daily work for a long time without any problems.

[koutcher]

After #917 the legacy refresh modes should now work as expected. Is this new one still necessary ?

[msudgh]

@koutcher Currently I'm using tig 2.4.1 and I don't see any periodic refresh which still needs to press Shift+R to refresh the status layout.

[koutcher]

It will be in the next version, for now you'd need to compile the master branch to use it.

[gdgp]

Built from master, for some reason set refresh-mode = auto was not working for me. However the following is working:

set refresh-mode = periodic
set refresh-interval = 1

Note: for large repos maybe increase the refresh interval.

[koutcher]

What you should expect when set refresh-mode = auto is that after opening the status view and staging a file, the change is also visible in main view, nothing more. If you want tig to actively look for changes in the directory then you got the right choice with periodic.

[gdgp]

@koutcher I see, thank you for clearing that up. Then I think I got mislead from reading the following in tigrc.5@master:
"refresh-mode (mixed) [manual|auto|after-command|periodic|]
Configures how views are refreshed based on modifications to watched files in the repository. When set to manual, nothing is refreshed automatically. When set to auto, views are refreshed when a modification is detected. When set to after-command only refresh after returning from an external command. When set to periodic, visible views are refreshed periodically using refresh-interval."

[koutcher]

Would it be less misleading if we change the documentation to When set to 'auto', views are refreshed when a modification is detected in another view. ?

[gdgp]

Yes, I think that surely helps.

[c02y]

When I'm in tig status mode, and use Enter a file to view the diff, when I modify the file outside tig, is it able to refresh the diff view automatically?

Currently I have to switch to the next file and switch back to previous file to refresh or exit the diff view and enter the diff view to show the diff , or manually refresh using my binding to the refresh command.