treemacs-git-mode not working

[CSRaghunandan]

Here is my treemacs config: https://github.com/CSRaghunandan/.emacs.d/blob/master/setup-files/setup-treemacs.el

emacs version: GNU Emacs 26.0.91 (build 1, x86_64-apple-darwin16.7.0, NS appkit-1504.83 Version 10.12.6 (Build 16G1212)) of 2018-02-26

treemacs version: 20180221.1229

After modifying or adding any new files, I'm not seeing any changes to faces for the modified/added files. Any idea why this is happening?

[CSRaghunandan]

Ok looks like I've to manually refresh the treemacs buffer for it to show git related modifications. I've treemacs-filewatch-mode enabled. But looks like that's not helping ?

[Alexander-Miller]

The answer is twofold:

• filewatch-mode only applies to nodes you expand after its activation. If you turn it on when treemacs is already open it's easiest to just kill and reopen treemacs.
• filewatch-mode will update when files are changed, which is enough to cover many, but not all use-cases. Treemacs cannot know about e.g. adding or committing files in git, since these actions don't make any changes to the actual files. For these a manual refresh is the only option, though for the future I want to ask the maintainers of magit to provide hooks that treemacs can use.

[CSRaghunandan]

filewatch-mode will update when files are changed, which is enough to cover many, but not all use-cases. Treemacs cannot know about e.g. adding or committing files in git, since these actions don't make any changes to the actual files. For these a manual refresh is the only option, though for the future I want to ask the maintainers of magit to provide hooks that treemacs can use.

Can use magit-post-refresh-hook to refresh treemacs. I've similar settings to update diff-hl in open buffer after running any magit command.

filewatch-mode only applies to nodes you expand after its activation. If you turn it on when treemacs is already open it's easiest to just kill and reopen treemacs.

Oh I didn't realize filewatch-mode works that way.

[Alexander-Miller]

Oh I didn't realize filewatch-mode works that way.

Makes things much easier on my part. I figured filewatch-mode is something you either turn on from the start or not at all.

Can use magit-post-refresh-hook to refresh treemacs.

That's a stopgap solution at best.

1. Treemacs knows how to run a local refresh for a single directory. With this hook I'd have no choice but to refresh everything.
2. magit-refresh runs many more times than treemacs requires refreshing. Depending on the size of your filetree and your hardware refreshing everything can incur a visible delay.

I'll get around this eventually, but first it requires a) magit's cooperation and b) me finishing my current project, which is teaching treemacs to display multiple file trees at once.

[Compro-Prasad]

You can keep a watch on the .git directory itself for any changes. Normal git status/log shouldn't mutate the state of the .git directory. Most of the other commands might change the .git directory. Doing a checkout means all files are changed along with the value of HEAD in .git, so you are still going to update the file tree.

[Alexander-Miller]

I ran a short test - just watched .git and checked what changes it produces. Adding an untracked file - one of the actions that treemacs cannot react to now - didn't do much other than produce a whole lot of of changes to index.lock. The index would also get locked every time I fire git status, so whenever you expand a directory node.

So for this use-case I could not detect the event I need to react to and only burdened myself with additional interference.

Doing a checkout means all files are changed along with the value of HEAD in .git

A checkout should not be an issue. Anything that changes actual files will be detected. The problem is when git does somethinh that does change the underlying file system. AFAIK that should be limited to adding untracked files and making commits.

[Compro-Prasad]

Should we really care about untracked files?

[Compro-Prasad]

What I can suggest is run a git status to collect untracked files when:

• Project is added to treemacs buffer
• Force refresh is done
• A new file is created

Watching for the whole project directory might be a thing which can help out in such situations but it will also count on the ignored files.

[Alexander-Miller]

Should we really care about untracked files? Yes, of course. Appropriately displaying ignored, changed, added, untracked or conflicted files is the entire point of git-mode. Watching for the whole project directory might be a thing which might also help out in such situations It sounds like you don't know how filewatch-mode works. Watching the entire project directory for filesystem changes - or, more accurately, the visible parts - is exactly what it does. Your three points are likewise just a subset of everything treemacs already pays attention to. The problem lies only in detecting those events that make no changes to the underlying file system. That's the part I'll need magit hooks for.

[Compro-Prasad]

What is the thing that doesn't make changes to the underlying file system but is important for us to watch?

[Alexander-Miller]

For example making a commit. That'll change a bunch of your files from being modified to being clean again.

[Compro-Prasad]

For that we can watch for changes in the .git directory.

[Alexander-Miller]

Not really. As already said above, adding an untracked file does nothing but produce a dozen index.lock changes (in addition to the general interference every time I fire git status). That's not a good indication for anything.

[Compro-Prasad]

Are we out of options?