Skip to content
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

Deleted files are still shown in projectile-find-file #1148

Closed
raxod502 opened this issue Jul 1, 2017 · 21 comments · Fixed by #1825
Closed

Deleted files are still shown in projectile-find-file #1148

raxod502 opened this issue Jul 1, 2017 · 21 comments · Fixed by #1825

Comments

@raxod502
Copy link
Contributor

raxod502 commented Jul 1, 2017

Expected behavior

Suppose that I have a Git repository with some files committed to it. When I delete one of those files in my working directory, it should no longer show up in projectile-find-file.

Actual behavior

All files in Git's index are shown in projectile-find-file. When I have renamed a file, this causes both the old path and the new path to show up in projectile-find-file. If the old path is listed earlier than the new path, this causes me to inadvertently re-create a file at the old path.

Steps to reproduce the problem

$ mkdir example-git-repo
$ cd example-git-repo
$ git init
$ touch existing-file nonexistent-file
$ git add existing-file nonexistent-file
$ git commit -m "Add two files"
$ rm nonexistent-file
$ emacs -Q
M-x projectile-find-file

Observe that both existing-file and nonexistent-file are listed, whereas only existing-file should be listed.

$ git add nonexistent-file
$ emacs -Q
M-x projectile-find-file

Observe that nonexistent-file is no longer listed if its deletion is added to the index.

Cause

This is because Projectile uses git ls-files in projectile-git-command, and git ls-files shows files in the index, not files in the working directory.

Environment & Version information

Projectile version information

Revision 56e262d, version 0.15.0snapshot.

Emacs version

GNU Emacs 25.2.1 from brew cask install emacs.

Operating system

                -/+:.           
               :++++.           
              /+++/.            OS: macOS Sierra 10.12.5 16F73 x86_64
      .:-::- .+/:-``.::-        Model: MacBookPro11,4
   .:/++++++/::::/++++++/:`     Kernel: 16.6.0
 .:///////////////////////:`    Uptime: 2 days, 8 hours, 4 mins
 ////////////////////////`      Packages: 203
-+++++++++++++++++++++++`       Shell: zsh 5.3.1
/++++++++++++++++++++++/        Resolution: 1440x900
/sssssssssssssssssssssss.       DE: Aqua
:ssssssssssssssssssssssss-      WM: Quartz Compositor
 osssssssssssssssssssssssso/`   Terminal: iTerm2
 `syyyyyyyyyyyyyyyyyyyyyyyy+`   Terminal Font: InputMono-Medium 12
  `ossssssssssssssssssssss/     CPU: Intel i7-4980HQ (8) @ 2.80GHz
    :ooooooooooooooooooo+.      GPU: Intel Iris Pro
     `:+oo+/:-..-:/+o+/-        Memory: 3607MiB / 16384MiB
@lfender6445
Copy link

Try M-x projectile-invalidate-cache to clear out deleted files

@raxod502
Copy link
Contributor Author

@lfender6445 This makes no difference.

@vyorkin
Copy link

vyorkin commented Apr 17, 2018

Same problem, projectile-invalidate-cache doesn't help, restarting emacs doesn't help too,
the file disappears when I stage it with git (I mean using git add). That's definitely related to git, just checked one more time: deleted files dissapear after git adding them. Sorry, I don't have enough knowledge to dig into it any further

@wladyslaws
Copy link

you have to do both, i.e. stage deletion with git along with cache invalidation afterwards

@raxod502
Copy link
Contributor Author

This is not true, as far as I can tell from the tests I just did. If you haven't staged the deletion, then invalidating the cache does nothing—the file will be shown regardless. If you have staged the deletion, then invalidating the cache also does nothing—the file will not be shown regardless.

@Andsbf
Copy link

Andsbf commented Oct 11, 2018

commenting here just to keep track of it!

@raxod502
Copy link
Contributor Author

@Andsbf There is a "subscribe to notifications" button that you can use to follow an issue without commenting.

@stale
Copy link

stale bot commented May 8, 2019

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contribution and understanding!

@stale stale bot added the Stale label May 8, 2019
@mmcnl
Copy link

mmcnl commented May 8, 2019

Just confirming that this issue is still reproducible with the current version of projectile. As I (like the original poster) find the current behavior confusing, I'm curious if anyone has found any workaround?

@stale stale bot removed the Stale label May 8, 2019
@renatofdds
Copy link

This is still reproducible. I just found out about it using Projectile 2.1.0snapshot. In the meantime as a workaround i set projectile-git-command to comm -23 <(git ls-files -co --exclude-standard | sort) <(git ls-files -d | sort) | tr '\n' '\0'

@tagirb
Copy link

tagirb commented Nov 19, 2019

My workaround was to replace git ls-files with fd:

  1. Add this to init.el:
(setq projectile-git-command "fd . -0 --type f --hidden --color=never")
  1. Add this to ~/.fdignore to ignore .git directories while --hidden is used as proposed here:
**/.git/

Still have to find out how to deal with the files forcefully checked-in into Git despite being ignored by .gitignore..

@stale
Copy link

stale bot commented May 18, 2020

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contribution and understanding!

@stale stale bot added the Stale label May 18, 2020
@raxod502
Copy link
Contributor Author

To my knowledge this is still a bug.

@stale stale bot removed the Stale label May 19, 2020
leodcs pushed a commit to leodcs/emacs.d that referenced this issue Oct 8, 2020
@stale
Copy link

stale bot commented Nov 15, 2020

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contribution and understanding!

@stale stale bot added the Stale label Nov 15, 2020
@raxod502
Copy link
Contributor Author

Unless I am mistaken, nothing has changed with regard to this bug.

@stale stale bot removed the Stale label Nov 16, 2020
@bbatsov bbatsov added the Bug label Dec 2, 2020
@bbatsov
Copy link
Owner

bbatsov commented Dec 2, 2020

This is because Projectile uses git ls-files in projectile-git-command, and git ls-files shows files in the index, not files in the working directory.

Yeah, that's true.

Seems to me the simplest way to solve this would be to adjust the command in question, although I'm not sure what would be the optimal replacement.

@raxod502
Copy link
Contributor Author

Relying on software such as fd might be an option, as suggested in #1148 (comment). I am not terribly familiar with the ecosystem of options, but I think it is likely that something suitable may exist.

@nilbacardit26
Copy link

Maybe that is a bit of track nowadays, but cleaning the tree by pushing the deleted files to git and then invalidating the cache solved the issue for me

@raxod502
Copy link
Contributor Author

raxod502 commented Sep 3, 2022

Correct, #1148 (comment) is still the best workaround.

@sergeyklay
Copy link

I found #1148 (comment) a suitable workaround for both Linux and macOS.

raxod502 added a commit to raxod502/projectile that referenced this issue Feb 28, 2023
When fd is installed, use it with appropriate options instead of git
ls-files in order to fix bbatsov#1148
@raxod502
Copy link
Contributor Author

Filed #1825 to solve this issue, and implemented radian-software/radian@75e3434 to patch it in my Emacs configuration.

bbatsov pushed a commit that referenced this issue Mar 12, 2023
When fd is installed, use it with appropriate options instead of git
ls-files in order to fix #1148
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.