github icon indicating copy to clipboard operation
github copied to clipboard

Github package does not show file changes until focus out and in again

Open smueller18 opened this issue 7 years ago • 2 comments

Description

For my git projects, I created a symlink from /home/user/git to /git. In the last few weeks (or months, I can't exactly remember), I had the following problem: After changing a file and saving it, the tree view highlights the file that has changed, but it is not shown in the unstaged changes area until another app gets the focus and atom gets it back. I created a couple of screenshots to demonstrate this behavior:

After opening a clean git project: image

After changing the readme file, the change is highlighted in the project tree but not listed in the unstaged changes area: image

After focus out and focus in event, the change is listed: image

I first thought #1741 is adressing the same behaviour, but as long as the file is listed in the unstaged changes area, the diffs are shown correctly in the main editor after clicking the file: image

Steps to reproduce

Setup a new git project and the github plugin works as expected:

cd /tmp
mkdir test
cd test
git init
touch README.md
git add .
git commit -m "initial commit"
atom .

Also, opening a project without a symlink to a root folder works:

cd /
ln -s /tmp/test /tmp/test2
atom /tmp/test2

But opening a project from the command line with a root symlink (or a nested path, e.g. /test/test), the behaviour is like described above:

cd /
sudo ln -s /tmp/test /test
atom /test

Workaround

Not using symlinks pointing to a root folder

Versions

Ubuntu 18.04 Atom : 1.31.2 Electron: 2.0.7 Chrome : 61.0.3163.100 Node : 8.9.3 Plugins: only plugins of the plain installation

smueller18 avatar Oct 16 '18 10:10 smueller18

Ahhh. On Linux we use a WorkspaceChangeObserver instead of a real, full filesystem watcher, because our old watcher implementation would eat through watch descriptors (especially if you had, say, a node_modules/ directory to deal with). The WorkspaceChangeObserver creates real watchers for .git/ but I bet we aren't handling symlinks properly in there.

Note that once atom/atom#17899 lands we may get rid of the WorkspaceChangeObserver anyway. We'll have to check to make sure this doesn't still happen then as well.

In any case, this is likely a missing fs.realpath() call somewhere. I'll mark it as a good first issue to see if anyone's interested in contributing before we get the chance to prioritize it 👌

smashwilson avatar Oct 17 '18 11:10 smashwilson

Any progress on this issue? I have my linux VMs infrastructure with symlinks to project directory. And I'm facing this annoying refresh bug. Thank you!

tarkh avatar Jun 14 '21 17:06 tarkh