-
Notifications
You must be signed in to change notification settings - Fork 151
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Org is rebuilt even though no source files have changed (just the mtime of the lisp subdir) #519
Comments
Maybe I was mistaken about what the find command does. Just now I looked at some source files for helm, which for some reason I really don’t know ended up in the ".git" directory getting an updated mtime (none of the current files inside it are updated).
|
I don't understand. Is the mtime of |
The mtime of the entire local repository. I tested with
when visiting So maybe this is a question of straight being able to accurately detect “real” or “relevant” changes to a repository, where a changed mtime of the repository directory because of added and removed files isn’t a relevant change, but triggers a rebuild with the current implementation. But it is of course a hard problem to do this in a good way. |
Closing as a duplicate of #508. Sorry for missing that before posting this. |
I suspect there is no workaround and we will have to prevent Flycheck from creating those temporary files. After all, it's not possible to tell what change caused the mtime on a directory to be updated. |
What's wrong
I often visit the source of org files, and even if I don’t change anything, the mtime of the
lisp
subdir in the org repo where all elisp files reside is often changed because flycheck creates temporary files that are later removed. The command for detecting changes which (as I understand it) should be something likefind org -name .git -prune -o -newermt CACHEDMTIME -print
will then outputlisp
and org will be rebuilt, even though no "real" changes to the source have occurred.This got a lot more noticeable now that I’m testing out the emacs
native-comp
branch and all fans go off at max when recompiling all the org elisp toeln
files 🙂.I suppose this only happens for repos like org where the elisp files are in a subdir. Temporary and removed files in the main repo directory resulting in changed mtime for that directory is not registered as a change. Would it be feasible with more precision for the change detection? But than we would risk to miss what should be detected as a change in other repos? For example only looking at elisp files won’t work, as it’s that’s clearly not enough for for many packages that contain for example C code like pdf-tools)?
Directions to reproduce
I created a
.emacs.d
with only thisinit.el
Then ran it:
emacs --quick --eval "(setq user-emacs-directory \"/home/aj/.emacs.d-test-straight\")" --eval "(setq user-init-file \"/home/aj/.emacs.d-test-straight/init.el\")" --load "/home/aj/.emacs.d-test-straight/init.el"
Straight, use-package and org is installed.
Quitting and restarting, everything works as expected.
Restarting now triggers a rebuild of org.
Version information
The text was updated successfully, but these errors were encountered: