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" notifications@github.com 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